summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/TraversalChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-261-0/+8
| | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 &registry); 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
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [analyzer] Make checkEndFunction() give access to the return statement.Reka Kovacs2018-07-161-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D49387 llvm-svn: 337215
* [analyzer] Add checker callback for beginning of function.Devin Coughlin2016-02-191-0/+6
| | | | | | | | | | Add a checker callback that is called when the analyzer starts analyzing a function either at the top level or when inlined. This will be used by a follow-on patch making the DeallocChecker path sensitive. Differential Revision: http://reviews.llvm.org/D17418 llvm-svn: 261293
* [C++11] Use 'nullptr'. StaticAnalyzer edition.Craig Topper2014-05-271-2/+2
| | | | llvm-svn: 209642
* [analyzer] Print return values from debug.DumpCalls checker.Jordan Rose2013-03-211-1/+23
| | | | | | Debug utility only, no functionality change. llvm-svn: 177649
* [analyzer] Rename callback EndPath -> EndFunctionAnna Zaks2013-01-031-4/+4
| | | | | | | This better reflects when callback is called and what the checkers are relying on. (Both names meant the same pre-IPA.) llvm-svn: 171432
* Include pruning and general cleanup.Benjamin Kramer2012-12-011-0/+1
| | | | llvm-svn: 169095
* [analyzer] Rename Calls.{h,cpp} to CallEvent.{h,cpp}. No functionality change.Jordan Rose2012-07-261-1/+1
| | | | llvm-svn: 160815
* [analyzer] Add debug.DumpCalls, which prints out any CallEvents it sees.Jordan Rose2012-07-101-2/+29
| | | | | | | | | | This is probably not so useful yet because it is not path-sensitive, though it does try to show inlining with indentation. This also adds a dump() method to CallEvent, which should be useful for debugging. llvm-svn: 160030
* [analyzer] Add a test that we are, in fact, doing a DFS on the ExplodedGraph.Jordan Rose2012-06-291-0/+57
Previously: ...the comment said DFS... ...the WorkList being instantiated said BFS... ...and the implementation was actually DFS... ...due to an unintentional change in 2010... ...and everything kept working anyway. This fixes our std::deque implementation of BFS, but switches back to a SmallVector-based implementation of DFS. We should probably still investigate the ramifications of DFS vs. BFS, especially for large functions (and especially when we hit our block path limit), since this might completely change our memory use. It can also mask some bugs and reveal others depending on when we halt analysis. But at least we will not have this kind of little mistake creep in again. llvm-svn: 159397
OpenPOWER on IntegriCloud