Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
8ee3dfd7 |
| 01-Jan-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Take SVal and NonLoc by value
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4 |
|
#
8a5cfdf7 |
| 25-Aug-2023 |
Donát Nagy <donat.nagy@ericsson.com> |
[analyzer][NFC] Remove useless class BuiltinBug
...because it provides no useful functionality compared to its base class `BugType`.
A long time ago there were substantial differences between `BugT
[analyzer][NFC] Remove useless class BuiltinBug
...because it provides no useful functionality compared to its base class `BugType`.
A long time ago there were substantial differences between `BugType` and `BuiltinBug`, but they were eliminated by commit 1bd58233 in 2009 (!). Since then the only functionality provided by `BuiltinBug` was that it specified `categories::LogicError` as the bug category and it stored an extra data member `desc`.
This commit sets `categories::LogicError` as the default value of the third argument (bug category) in the constructors of BugType and replaces use of the `desc` field with simpler logic.
Note that `BugType` has a data member `Description` and a non-virtual method `BugType::getDescription()` which queries it; these are distinct from the member `desc` of `BuiltinBug` and the identically named method `BuiltinBug::getDescription()` which queries it. This confusing name collision was a major motivation for the elimination of `BuiltinBug`.
As this commit touches many files, I avoided functional changes and left behind FIXME notes to mark minor issues that should be fixed later.
Differential Revision: https://reviews.llvm.org/D158855
show more ...
|
Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
5114db93 |
| 10-Apr-2022 |
Vince Bridgers <vince.a.bridgers@gmail.com> |
[analyzer] Clean checker options from bool to DefaultBool (NFC)
A recent review emphasized the preference to use DefaultBool instead of bool for checker options. This change is a NFC and cleans up s
[analyzer] Clean checker options from bool to DefaultBool (NFC)
A recent review emphasized the preference to use DefaultBool instead of bool for checker options. This change is a NFC and cleans up some of the instances where bool was used, and could be changed to DefaultBool.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D123464
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
1c8f999e |
| 05-Apr-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][CallAndMessage] Add checker options for each bug type
iAs listed in the summary D77846, we have 5 different categories of bugs we're checking for in CallAndMessage. I think the documentat
[analyzer][CallAndMessage] Add checker options for each bug type
iAs listed in the summary D77846, we have 5 different categories of bugs we're checking for in CallAndMessage. I think the documentation placed in the code explains my thought process behind my decisions quite well.
A non-obvious change I had here is removing the entry for CallAndMessageUnInitRefArg. In fact, I removed the CheckerNameRef typed field back in D77845 (it was dead code), so that checker didn't really exist in any meaningful way anyways.
Differential Revision: https://reviews.llvm.org/D77866
show more ...
|
#
eeff1a97 |
| 05-Apr-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][CallAndMessage][NFC] Split up checkPreCall
The patch aims to use CallEvents interface in a more principled manner, and also to highlight what this checker really does. It in fact checks f
[analyzer][CallAndMessage][NFC] Split up checkPreCall
The patch aims to use CallEvents interface in a more principled manner, and also to highlight what this checker really does. It in fact checks for 5 different kinds of errors (from checkPreCall, that is):
* Invalid function pointer related errors * Call of methods from an invalid C++ this object * Function calls with incorrect amount of parameters * Invalid arguments for operator delete * Pass of uninitialized values to pass-by-value parameters
In a previous patch I complained that this checker is responsible for emitting a lot of different diagnostics all under core.CallAndMessage's name, and this patch shows where we could start to assign different diagnostics to different entities.
Differential Revision: https://reviews.llvm.org/D77846
show more ...
|
#
3d0d2fef |
| 14-Apr-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
analyzer][CallAndMessage][NFC] Change old callbacks to rely on CallEvent
The following series of patches has something similar in mind with D77474, with the same goal to finally end incorrect checke
analyzer][CallAndMessage][NFC] Change old callbacks to rely on CallEvent
The following series of patches has something similar in mind with D77474, with the same goal to finally end incorrect checker names for good. Despite CallAndMessage not suffering from this particular issue, it is a dependency for many other checkers, which is problematic, because we don't really want dependencies to also emit diagnostics (reasoning for this is also more detailed in D77474).
CallAndMessage also has another problem, namely that it is responsible for a lot of reports. You'll soon learn that this isn't really easy to solve for compatibility reasons, but that is the topic of followup patches.
Differential Revision: https://reviews.llvm.org/D77845
show more ...
|
#
bda3dd0d |
| 27-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patc
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered.
Differential Revision: https://reviews.llvm.org/D75271
show more ...
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
#
72649423 |
| 12-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, a
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks.
This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks.
Differential Revision: https://reviews.llvm.org/D67140
llvm-svn: 371760
show more ...
|
Revision tags: llvmorg-9.0.0-rc4 |
|
#
2f169e7c |
| 09-Sep-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.
Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by cons
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.
Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type.
This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes.
Differential Revision: https://reviews.llvm.org/D66572
llvm-svn: 371450
show more ...
|
Revision tags: llvmorg-9.0.0-rc3 |
|
#
2b3d49b6 |
| 14-Aug-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement o
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
show more ...
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
#
204bf2bb |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution i
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution is to assert when CheckerManager::getChecker is called on an unregistered checker, and assert when CheckerManager::registerChecker is called on a checker that is already registered.
Differential Revision: https://reviews.llvm.org/D55429
llvm-svn: 352292
show more ...
|
#
8fd74ebf |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep wi
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
show more ...
|
#
058a7a45 |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. T
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways.
A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed.
This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953
Differential Revision: https://reviews.llvm.org/D55424
llvm-svn: 352277
show more ...
|
Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
76a21502 |
| 15-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs.
This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
b2cf0063 |
| 23-Oct-2018 |
George Karpenkov <ekarpenkov@apple.com> |
[analyzer] Rename trackNullOrUndefValue to trackExpressionValue
trackNullOrUndefValue is a long and confusing name, and it does not actually reflect what the function is doing. Give a function a new
[analyzer] Rename trackNullOrUndefValue to trackExpressionValue
trackNullOrUndefValue is a long and confusing name, and it does not actually reflect what the function is doing. Give a function a new name, with a relatively clear semantics.
Also remove some dead code.
Differential Revision: https://reviews.llvm.org/D52758
llvm-svn: 345064
show more ...
|
#
c55e9975 |
| 13-Oct-2018 |
Benjamin Kramer <benny.kra@googlemail.com> |
Move some helpers from the global namespace into anonymous ones.
llvm-svn: 344468
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3 |
|
#
574d78e7 |
| 29-Aug-2018 |
George Karpenkov <ekarpenkov@apple.com> |
[analyzer] Improve tracing for uninitialized struct fields
rdar://13729267
Differential Revision: https://reviews.llvm.org/D51323
llvm-svn: 340986
|
#
eae57a2b |
| 29-Aug-2018 |
George Karpenkov <ekarpenkov@apple.com> |
[analyzer] [NFC] Move class definition out of the function
Differential Revision: https://reviews.llvm.org/D51322
llvm-svn: 340964
|
Revision tags: llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
#
3ef5deb3 |
| 12-Dec-2017 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] In getSVal() API, disable auto-detection of void type as char type.
This is a follow-up from r314910. When a checker developer attempts to dereference a location in memory through Program
[analyzer] In getSVal() API, disable auto-detection of void type as char type.
This is a follow-up from r314910. When a checker developer attempts to dereference a location in memory through ProgramState::getSVal(Loc) or ProgramState::getSVal(const MemRegion *), without specifying the second optional QualType parameter for the type of the value he tries to find at this location, the type is auto-detected from location type. If the location represents a value beyond a void pointer, we thought that auto-detecting the type as 'char' is a good idea. However, in most practical cases, the correct behavior would be to specify the type explicitly, as it is available from other sources, and the few cases where we actually need to take a 'char' are workarounds rather than an intended behavior. Therefore, try to fail with an easy-to-understand assertion when asked to read from a void pointer location.
Differential Revision: https://reviews.llvm.org/D38801
llvm-svn: 320451
show more ...
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
#
3d8d6ed0 |
| 08-Mar-2017 |
Daniel Marjamaki <daniel.marjamaki@evidente.se> |
[analyzer] Clarify 'uninitialized function argument' messages
Differential Revision: https://reviews.llvm.org/D30341
llvm-svn: 297283
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
8693adfd |
| 15-Nov-2016 |
Devin Coughlin <dcoughlin@apple.com> |
[analyzer] Add check for when block is called with too few arguments.
The CallAndMessageChecker has an existing check for when a function pointer is called with too few arguments. Extend this logic
[analyzer] Add check for when block is called with too few arguments.
The CallAndMessageChecker has an existing check for when a function pointer is called with too few arguments. Extend this logic to handle the block case, as well. While we're at it, do a drive-by grammar correction ("less" --> "fewer") on the diagnostic text.
llvm-svn: 287001
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
#
d0891868 |
| 23-Mar-2016 |
Chih-Hung Hsieh <chh@google.com> |
[analyzer] Fix typo s/initalize/initialize/
Differential Revision: http://reviews.llvm.org/D18363
llvm-svn: 264164
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
#
6f3ff22e |
| 30-Oct-2015 |
Tim Northover <tnorthover@apple.com> |
Support watchOS and tvOS driver options
This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and
Support watchOS and tvOS driver options
This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and tvOS.
llvm-svn: 251706
show more ...
|
#
e335f259 |
| 04-Oct-2015 |
Craig Topper <craig.topper@gmail.com> |
SourceRanges are small and trivially copyable, don't them by reference.
llvm-svn: 249259
|