summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer][NFC] Merge ClangCheckerRegistry to CheckerRegistryKristof Umann2018-12-152-99/+74
| | | | | | | | | | | Now that CheckerRegistry lies in Frontend, we can finally eliminate ClangCheckerRegistry. Fortunately, this also provides us with a DiagnosticsEngine, so I went ahead and removed some parameters from it's methods. Differential Revision: https://reviews.llvm.org/D54437 llvm-svn: 349280
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-15102-170/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Prefer returns values to out-params in CheckerRegistry.cppKristof Umann2018-12-152-95/+53
| | | | | | | | | | | | | | | Renaming collectCheckers to getEnabledCheckers Changing the functionality to acquire all enabled checkers, rather then collect checkers for a specific CheckerOptInfo (for example, collecting all checkers for { "core", true }, which meant enabling all checkers from the core package, which was an unnecessary complication). Removing CheckerOptInfo, instead of storing whether the option was claimed via a field, we handle errors immediately, as getEnabledCheckers can now access a DiagnosticsEngine. Realize that the remaining information it stored is directly accessible through AnalyzerOptions.CheckerControlList. Fix a test with -analyzer-disable-checker -verify accidentally left in. llvm-svn: 349274
* [analyzer] Assume that we always have a SubEngine availableGabor Horvath2018-12-157-49/+36
| | | | | | | | The removed codepath was dead. Differential Revision: https://reviews.llvm.org/D55697 llvm-svn: 349266
* Revert "[analyzer] MoveChecker: Add checks for dereferencing a smart pointer..."Artem Dergachev2018-12-151-149/+51
| | | | | | | | This reverts commit r349226. Fails on an MSVC buildbot. llvm-svn: 349233
* Move static analyzer core diagnostics to common.Richard Trieu2018-12-151-1/+0
| | | | llvm-svn: 349230
* [analyzer] Fix unknown block calls to have zero parameters.Artem Dergachev2018-12-151-1/+1
| | | | | | | | | | | | Right now they report to have one parameter with null decl, because initializing an ArrayRef of pointers with a nullptr yields an ArrayRef to an array of one null pointer. Fixes a crash in the OSObject section of RetainCountChecker. Differential Revision: https://reviews.llvm.org/D55671 llvm-svn: 349229
* [analyzer] ObjCDealloc: Fix a crash when a class attempts to deallocate a class.Artem Dergachev2018-12-151-0/+4
| | | | | | | | | | | | | | | | | | The checker wasn't prepared to see the dealloc message sent to the class itself rather than to an instance, as if it was +dealloc. Additionally, it wasn't prepared for pure-unknown or undefined self values. The new guard covers that as well, but it is annoying to test because both kinds of values shouldn't really appear and we generally want to get rid of all of them (by modeling unknown values with symbols and by warning on use of undefined values before they are used). The CHECK: directive for FileCheck at the end of the test looks useless, so i removed it. Differential Revision: https://reviews.llvm.org/D55680 llvm-svn: 349228
* [analyzer] ObjCContainers: Track index values.Artem Dergachev2018-12-151-0/+17
| | | | | | | | | | | | Use trackExpressionValue() (previously known as trackNullOrUndefValue()) to track index value in the report, so that the user knew what Static Analyzer thinks the index is. Additionally, implement printState() to help debugging the checker later. Differential Revision: https://reviews.llvm.org/D55458 llvm-svn: 349227
* [analyzer] MoveChecker: Add checks for dereferencing a smart pointer after move.Artem Dergachev2018-12-151-51/+149
| | | | | | | | | | | | | | | | | | | Calling operator*() or operator->() on a null STL smart pointer is undefined behavior. Smart pointers are specified to become null after being moved from. So we can't warn on arbitrary method calls, but these two operators definitely make no sense. The new bug is fatal because it's an immediate UB, unlike other use-after-move bugs. The work on a more generic null smart pointer dereference checker is still pending. Differential Revision: https://reviews.llvm.org/D55388 llvm-svn: 349226
* [analyzer] MoveChecker: NFC: De-duplicate a few checks.Artem Dergachev2018-12-151-82/+88
| | | | | | | | No functional change intended. Differential Revision: https://reviews.llvm.org/D55387 llvm-svn: 349225
* Using llvm::find_if() instead of a range-based for loop; NFC.Aaron Ballman2018-12-141-12/+9
| | | | | | This addresses post-commit review feedback from r349188. llvm-svn: 349197
* [analyzer] MoveChecker Pt.6: Suppress the warning for the move-safe STL classes.Artem Dergachev2018-12-141-15/+50
| | | | | | | | | | | Some C++ standard library classes provide additional guarantees about their state after move. Suppress warnings on such classes until a more precise behavior is implemented. Warnings for locals are not suppressed anyway because it's still most likely a bug. Differential Revision: https://reviews.llvm.org/D55307 llvm-svn: 349191
* [analyzer] MoveChecker: Improve invalidation policies.Artem Dergachev2018-12-141-15/+31
| | | | | | | | | | | | | | | | | If a moved-from object is passed into a conservatively evaluated function by pointer or by reference, we assume that the function may reset its state. Make sure it doesn't apply to const pointers and const references. Add a test that demonstrates that it does apply to rvalue references. Additionally, make sure that the object is invalidated when its contents change for reasons other than invalidation caused by evaluating a call conservatively. In particular, when the object's fields are manipulated directly, we should assume that some sort of reset may be happening. Differential Revision: https://reviews.llvm.org/D55289 llvm-svn: 349190
* Update our SARIF support from 10-10 to 11-28.Aaron Ballman2018-12-141-25/+54
| | | | | | | | | | | | | Functional changes include: * The run.files property is now an array instead of a mapping. * fileLocation objects now have a fileIndex property specifying the array index into run.files. * The resource.rules property is now an array instead of a mapping. * The result object was given a ruleIndex property that is an index into the resource.rules array. * rule objects now have their "id" field filled out in addition to the name field. * Updated the schema and spec version numbers to 11-28. llvm-svn: 349188
* [analyzer][CStringChecker] evaluate explicit_bzeroDavid Carlier2018-12-111-5/+55
| | | | | | | | | | | | | - explicit_bzero has limited scope/usage only for security/crypto purposes but is non-optimisable version of memset/0 and bzero. - explicit_memset has similar signature and semantics as memset but is also a non-optimisable version. Reviewers: NoQ Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D54592 llvm-svn: 348884
* [analyzer] Remove memoization from RunLoopAutoreleaseLeakCheckerGeorge Karpenkov2018-12-111-26/+8
| | | | | | | | | | | | | Memoization dose not seem to be necessary, as other statement visitors run just fine without it, and in fact seems to be causing memory corruptions. Just removing it instead of investigating the root cause. rdar://45945002 Differential Revision: https://reviews.llvm.org/D54921 llvm-svn: 348822
* [analyzer] Hack for backwards compatibility for options for RetainCountChecker.George Karpenkov2018-12-111-1/+13
| | | | | | To be removed once the clients update. llvm-svn: 348821
* [analyzer] Display a diagnostics when an inlined function violates its ↵George Karpenkov2018-12-111-12/+93
| | | | | | | | | | | | | os_consumed summary This is currently a diagnostics, but might be upgraded to an error in the future, especially if we introduce os_return_on_success attributes. rdar://46359592 Differential Revision: https://reviews.llvm.org/D55530 llvm-svn: 348820
* [analyzer] Resolve another bug where the name of the leaked object was not ↵George Karpenkov2018-12-111-3/+3
| | | | | | | | printed properly Differential Revision: https://reviews.llvm.org/D55528 llvm-svn: 348819
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-1019-30/+30
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* Stop tracking retain count of OSObject after escape to void * / other ↵George Karpenkov2018-12-081-0/+23
| | | | | | | | | | | | | | primitive types Escaping to void * / uint64_t / others non-OSObject * should stop tracking, as such functions can have heterogeneous semantics depending on context, and can not always be annotated. rdar://46439133 Differential Revision: https://reviews.llvm.org/D55465 llvm-svn: 348675
* [analyzer] Move out tracking retain count for OSObjects into a separate checkerGeorge Karpenkov2018-12-073-84/+140
| | | | | | | | | Allow enabling and disabling tracking of ObjC/CF objects separately from tracking of OS objects. Differential Revision: https://reviews.llvm.org/D55400 llvm-svn: 348638
* [analyzer] RetainCountChecker: remove untested, unused, incorrect option ↵George Karpenkov2018-12-073-17/+7
| | | | | | | | | | | | IncludeAllocationLine The option has no tests, is not used anywhere, and is actually incorrect: it prints the line number without the reference to a file, which can be outright incorrect. Differential Revision: https://reviews.llvm.org/D55385 llvm-svn: 348637
* [CTU] Add DisplayCTUProgress analyzer switchGabor Marton2018-12-071-2/+2
| | | | | | | | | | | | | | | | Summary: With a new switch we may be able to print to stderr if a new TU is being loaded during CTU. This is very important for higher level scripts (like CodeChecker) to be able to parse this output so they can create e.g. a zip file in case of a Clang crash which contains all the related TU files. Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Differential Revision: https://reviews.llvm.org/D55135 llvm-svn: 348594
* [analyzer] Rely on os_consumes_this attribute to signify that the method ↵George Karpenkov2018-12-061-0/+3
| | | | | | | | call consumes a reference for "this" Differential Revision: https://reviews.llvm.org/D55158 llvm-svn: 348533
* [analyzer] Fix an infinite recursion bug while checking parent methods in ↵George Karpenkov2018-12-061-1/+1
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D55351 llvm-svn: 348531
* [analyzer] Attribute for RetainCountChecker for OSObject should propagate ↵George Karpenkov2018-12-051-18/+51
| | | | | | | | | | with inheritance rdar://46388388 Differential Revision: https://reviews.llvm.org/D55154 llvm-svn: 348396
* [Analyzer] Iterator Checker - Forbid decrements past the begin() and ↵Adam Balogh2018-12-041-90/+154
| | | | | | | | | | | | | | | | | | | | increments past the end() of containers Previously, the iterator range checker only warned upon dereferencing of iterators outside their valid range as well as increments and decrements of out-of-range iterators where the result remains out-of-range. However, the C++ standard is more strict than this: decrementing begin() or incrementing end() results in undefined behaviour even if the iterator is not dereferenced afterwards. Coming back to the range once out-of-range is also undefined. This patch corrects the behaviour of the iterator range checker: warnings are given for any operation whose result is ahead of begin() or past the end() (which is the past-end iterator itself, thus now we are speaking of past past-the-end). Differential Revision: https://reviews.llvm.org/D53812 llvm-svn: 348245
* [Analyzer] Iterator Checkers - Use the region of the topmost base class for ↵Adam Balogh2018-12-042-39/+30
| | | | | | | | | | | | | | | | | | iterators stored in a region If an iterator is represented by a derived C++ class but its comparison operator is for its base the iterator checkers cannot recognize the iterators compared. This results in false positives in very straightforward cases (range error when dereferencing an iterator after disclosing that it is equal to the past-the-end iterator). To overcome this problem we always use the region of the topmost base class for iterators stored in a region. A new method called getMostDerivedObjectRegion() was added to the MemRegion class to get this region. Differential Revision: https://reviews.llvm.org/D54466 llvm-svn: 348244
* [analyzer] MoveChecker: Add more common state resetting methods.Artem Dergachev2018-12-041-1/+4
| | | | | | | | | Includes "resize" and "shrink" because they can reset the object to a known state in certain circumstances. Differential Revision: https://reviews.llvm.org/D54563 llvm-svn: 348235
* [analyzer] MoveChecker: Improve warning and note messages.Artem Dergachev2018-12-041-24/+55
| | | | | | | | | | | | | | | | | | | The warning piece traditionally describes the bug itself, i.e. "The bug is a _____", eg. "Attempt to delete released memory", "Resource leak", "Method call on a moved-from object". Event pieces produced by the visitor are usually in a present tense, i.e. "At this moment _____": "Memory is released", "File is closed", "Object is moved". Additionally, type information is added into the event pieces for STL objects (in order to highlight that it is in fact an STL object), and the respective event piece now mentions that the object is left in an unspecified state after it was moved, which is a vital piece of information to understand the bug. Differential Revision: https://reviews.llvm.org/D54560 llvm-svn: 348229
* [analyzer] MoveChecker: Restrict to locals and std:: objects.Artem Dergachev2018-12-031-10/+68
| | | | | | | | | | | | | | | | | | | | | | | | In general case there use-after-move is not a bug. It depends on how the move-constructor or move-assignment is implemented. In STL, the convention that applies to most classes is that the move-constructor (-assignment) leaves an object in a "valid but unspecified" state. Using such object without resetting it to a known state first is likely a bug. Objects Local value-type variables are special because due to their automatic lifetime there is no intention to reuse space. If you want a fresh object, you might as well make a new variable, no need to move from a variable and than re-use it. Therefore, it is not always a bug, but it is obviously easy to suppress when it isn't, and in most cases it indeed is - as there's no valid intention behind the intentional use of a local after move. This applies not only to local variables but also to parameter variables, not only of value type but also of rvalue reference type (but not to lvalue references). Differential Revision: https://reviews.llvm.org/D54557 llvm-svn: 348210
* [analyzer] MoveChecker: NFC: Remove the workaround for the "zombie symbols" bug.Artem Dergachev2018-12-031-44/+7
| | | | | | | | | | | | | | | | | | The checker had extra code to clean up memory regions that were sticking around in the checker without ever being cleaned up due to the bug that was fixed in r347953. Because of that, if a region was moved from, then became dead, and then reincarnated, there were false positives. Why regions are even allowed to reincarnate is a separate story. Luckily, this only happens for local regions that don't produce symbols when loaded from. No functional change intended. The newly added test demonstrates that even though no cleanup is necessary upon destructor calls, the early return cannot be removed. It was not failing before the patch. Differential Revision: https://reviews.llvm.org/D54372 llvm-svn: 348208
* [analyzer] Rename MisusedMovedObjectChecker to MoveCheckerArtem Dergachev2018-12-032-33/+26
| | | | | | | | | This follows the Static Analyzer's tradition to name checkers after things in which they find bugs, not after bugs they find. Differential Revision: https://reviews.llvm.org/D54556 llvm-svn: 348201
* [analyzer] Dump stable identifiers for objects under construction.Artem Dergachev2018-12-031-2/+10
| | | | | | | | | | This continues the work that was started in r342313, which now gets applied to object-under-construction tracking in C++. Makes it possible to debug temporaries by dumping exploded graphs again. Differential Revision: https://reviews.llvm.org/D54459 llvm-svn: 348200
* [AST] [analyzer] NFC: Reuse code in stable ID dumping methods.Artem Dergachev2018-12-032-8/+2
| | | | | | | | Use the new fancy method introduced in r348197 to simplify some code. Differential Revision: https://reviews.llvm.org/D54488 llvm-svn: 348199
* Re-apply r347954 "[analyzer] Nullability: Don't detect post factum violation..."Artem Dergachev2018-12-031-6/+16
| | | | | | | | | | | Buildbot failures were caused by an unrelated UB that was introduced in r347943 and fixed in r347970. Also the revision was incorrectly specified as r344580 during revert. Differential Revision: https://reviews.llvm.org/D54017 llvm-svn: 348188
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-307-16/+20
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-307-20/+16
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* [analyzer] Evaluate all non-checker config options before analysisKristof Umann2018-11-3017-154/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
* Revert "Reverting r347949-r347951 because they broke the test bots."George Karpenkov2018-11-301-11/+17
| | | | | | | | This reverts commit 5bad6129c012fbf186eb055be49344e790448ecc. Hopefully fixing the issue which was breaking the bots. llvm-svn: 348030
* [analyzer][PlistMacroExpansion] Part 5.: Support for # and ##Kristof Umann2018-11-301-8/+17
| | | | | | | | | From what I can see, this should be the last patch needed to replicate macro argument expansions. Differential Revision: https://reviews.llvm.org/D52988 llvm-svn: 348025
* Reverting r347949-r347951 because they broke the test bots.Aaron Ballman2018-11-301-18/+4
| | | | | | http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/440/steps/ninja%20check%202/logs/FAIL%3A%20Clang%3A%3Aosobject-retain-release.cpp llvm-svn: 348020
* Fix warning about unused variable [NFC]Mikael Holmen2018-11-301-1/+1
| | | | llvm-svn: 347987
* lyzer] [HOTFIX!] SValBuilder crash when ↵Adam Balogh2018-11-301-3/+4
| | | | | | | | | | | | | `aggressive-binary-operation-simplification` enabled During the review of D41938 a condition check with an early exit accidentally slipped into a branch, leaving the other branch unprotected. This may result in an assertion later on. This hotfix moves this contition check outside of the branch. Differential Revision: https://reviews.llvm.org/D55051 llvm-svn: 347981
* Fix a use-after-scope bug.Haojian Wu2018-11-301-1/+1
| | | | llvm-svn: 347970
* Revert r344580 "[analyzer] Nullability: Don't detect post factum violation..."Artem Dergachev2018-11-301-16/+6
| | | | | | Fails under ASan! llvm-svn: 347956
* [analyzer] MallocChecker: Avoid redundant transitions.Artem Dergachev2018-11-301-2/+11
| | | | | | | | | | | | | | Don't generate a checker-tagged node unconditionally on the first checkDeadSymbols callback when no pointers are tracked. This is a tiny performance optimization; it may change the behavior slightly by making Static Analyzer bail out on max-nodes one node later (which is good) but any test would either break for no good reason or become useless every time someone sneezes. Differential Revision: https://reviews.llvm.org/D54013 llvm-svn: 347955
* [analyzer] Nullability: Don't detect post factum violation on concrete values.Artem Dergachev2018-11-301-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | The checker suppresses warnings on paths on which a nonnull value is assumed to be nullable. This probably deserves a warning, but it's a separate story. Now, because dead symbol collection fires in pretty random moments, there sometimes was a situation when dead symbol collection fired after computing a parameter but before actually evaluating call enter into the function, which triggered the suppression when the argument was null in the first place earlier than the obvious warning for null-to-nonnull was emitted, causing false negatives. Only trigger the suppression for symbols, not for concrete values. It is impossible to constrain a concrete value post-factum because it is impossible to constrain a concrete value at all. This covers all the necessary cases because by the time we reach the call, symbolic values should be either not constrained to null, or already collapsed into concrete null values. Which in turn happens because they are passed through the Store, and the respective collapse is implemented as part of getSVal(), which is also weird. Differential Revision: https://reviews.llvm.org/D54017 llvm-svn: 347954
OpenPOWER on IntegriCloud