summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-261-1/+1
| | | | | | | | | | | | | 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
* [analyzer] Reimplement dependencies between checkersKristof Umann2019-01-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-261-0/+4
| | | | | | | | | | | | | | | | | | 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
* Revert "Fix failing MSan bots"George Karpenkov2019-01-181-2/+2
| | | | | | | | This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778. Revert with a fix. llvm-svn: 351575
* Fix failing MSan botsVlad Tsyrklevich2019-01-181-2/+2
| | | | | | | Revert r351508-351514, this block of changes introduced a consistent MSan failure on the sanitizer bots. llvm-svn: 351528
* [analyzer] Extend BugType constructor to accept "SuppressOnSink" as a parameterGeorge Karpenkov2019-01-181-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D56884 llvm-svn: 351510
* [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
* [analyzer] [NFC] Remove unused parameters, as found by -Wunused-parameterGeorge Karpenkov2018-09-281-3/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D52640 llvm-svn: 343353
* [analyzer] Do not run visitors until the fixpoint, run only once.George Karpenkov2018-06-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current implementation, we run visitors until the fixed point is reached. That is, if a visitor adds another visitor, the currently processed path is destroyed, all diagnostics is discarded, and it is regenerated again, until it's no longer modified. This pattern has a few negative implications: - This loop does not even guarantee to terminate. E.g. just imagine two visitors bouncing a diagnostics around. - Performance-wise, e.g. for sqlite3 all visitors are being re-run at least 10 times for some bugs. We have already seen a few reports where it leads to timeouts. - If we want to add more computationally intense visitors, this will become worse. - From architectural standpoint, the current layout requires copying visitors, which is conceptually wrong, and can be annoying (e.g. no unique_ptr on visitors allowed). The proposed change is a much simpler architecture: the outer loop processes nodes upwards, and whenever the visitor is added it only processes current nodes and above, thus guaranteeing termination. Differential Revision: https://reviews.llvm.org/D47856 llvm-svn: 335666
* [analyzer] Remove the unused method declaration in `ValistChecker.cpp`.Henry Wong2018-03-301-1/+0
| | | | | | | | | | | | | | Summary: `getVariableNameFromRegion()` seems useless. Reviewers: xazax.hun, george.karpenkov Reviewed By: xazax.hun Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45081 llvm-svn: 328860
* [analyzer] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the ↵George Karpenkov2018-01-171-1/+1
| | | | | | | | | | | | | | | | | | helper is used consistently In most cases using `N->getState()->getSVal(E, N->getLocationContext())` is ugly, verbose, and also opens up more surface area for bugs if an inconsistent location context is used. This patch introduces a helper on an exploded node, and ensures consistent usage of either `ExplodedNode::getSVal` or `CheckContext::getSVal` across the codebase. As a result, a large number of redundant lines is removed. Differential Revision: https://reviews.llvm.org/D42155 llvm-svn: 322753
* [analyzer] Fix some check's output plist not containing the check nameGabor Horvath2018-01-061-7/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D41538 llvm-svn: 321933
* [analyzer] Fix memory error bug category capitalization.Artem Dergachev2017-05-031-2/+3
| | | | | | | | | | | | It was written as "Memory Error" in most places and as "Memory error" in a few other places, however it is the latter that is more consistent with other categories (such as "Logic error"). rdar://problem/31718115 Differential Revision: https://reviews.llvm.org/D32702 llvm-svn: 302016
* [analyzer] Fix a rare crash for valist check.Gabor Horvath2017-03-131-6/+2
| | | | | | | | | It looks like on some host-triples the result of a valist related expr can be a LazyCompoundVal. Handle that case in the check. Patch by Abramo Bagnara! llvm-svn: 297619
* [analyzer] Improve valist checks and move it out from alpha state.Gabor Horvath2017-03-071-24/+65
| | | | | | | | | This patch makes the valist check more robust to the different AST variants on different platforms and also fixes a FIXME. Differential Revision: https://reviews.llvm.org/D30157 llvm-svn: 297153
* Migrate PathDiagnosticPiece to std::shared_ptrDavid Blaikie2017-01-051-6/+6
| | | | | | | Simplifies and makes explicit the memory ownership model rather than implicitly passing/acquiring ownership. llvm-svn: 291143
* Reapply "[analyzer] Added valist related checkers."Gabor Horvath2016-08-221-0/+373
| | | | | | Differential Revision: https://reviews.llvm.org/D15227 llvm-svn: 279427
* revert [analyzer] Added valist related checkers.Gabor Horvath2016-08-181-373/+0
| | | | llvm-svn: 279043
* [analyzer] Added valist related checkers.Gabor Horvath2016-08-181-0/+373
Differential Revision: https://reviews.llvm.org/D15227 llvm-svn: 279041
OpenPOWER on IntegriCloud