summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Fix some expressions staying live too long. Add a debug checker.Artem Dergachev2018-12-161-0/+19
| | | | | | | | | | | | | | | | | | | | | StaticAnalyzer uses the CFG-based RelaxedLiveVariables analysis in order to, in particular, figure out values of which expressions are still needed. When the expression becomes "dead", it is garbage-collected during the dead binding scan. Expressions that constitute branches/bodies of control flow statements, eg. `E1' in `if (C1) E1;' but not `E2' in `if (C2) { E2; }', were kept alive for too long. This caused false positives in MoveChecker because it relies on cleaning up loop-local variables when they go out of scope, but some of those live-for-too-long expressions were keeping a reference to those variables. Fix liveness analysis to correctly mark these expressions as dead. Add a debug checker, debug.DumpLiveStmts, in order to test expressions liveness. Differential Revision: https://reviews.llvm.org/D55566 llvm-svn: 349320
* [analyzer][MallocChecker] Improve warning messages on double-delete errorsKristof Umann2018-12-151-2/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D54834 llvm-svn: 349283
* [analyzer][MallocChecker][NFC] Document and reorganize some functionsKristof Umann2018-12-151-422/+714
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch merely reorganizes some things, and features no functional change. In detail: * Provided documentation, or moved existing documentation in more obvious places. * Added dividers. (the //===----------===// thing). * Moved getAllocationFamily, printAllocDeallocName, printExpectedAllocName and printExpectedDeallocName in the global namespace on top of the file where AllocationFamily is declared, as they are very strongly related. * Moved isReleased and MallocUpdateRefState near RefState's definition for the same reason. * Realloc modeling was very poor in terms of variable and structure naming, as well as documentation, so I renamed some of them and added much needed docs. * Moved function IdentifierInfos to a separate struct, and moved isMemFunction, isCMemFunction adn isStandardNewDelete inside it. This makes the patch affect quite a lot of lines, should I extract it to a separate one? * Moved MallocBugVisitor out of MallocChecker. * Preferred switches to long else-if branches in some places. * Neatly organized some RUN: lines. Differential Revision: https://reviews.llvm.org/D54823 llvm-svn: 349281
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-1598-165/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Assume that we always have a SubEngine availableGabor Horvath2018-12-151-1/+1
| | | | | | | | 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
* [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
* [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
* [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-1013-16/+16
| | | | | | | | | | | | | | 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-072-10/+13
| | | | | | | | | 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
* [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-041-39/+21
| | | | | | | | | | | | | | | | | | 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
* 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-304-9/+15
| | | | | | | | | 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-304-15/+9
| | | | | | | | | | 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-302-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix warning about unused variable [NFC]Mikael Holmen2018-11-301-1/+1
| | | | llvm-svn: 347987
* 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
* [analyzer] Fix the "Zombie Symbols" bug.Artem Dergachev2018-11-308-42/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's an old bug that consists in stale references to symbols remaining in the GDM if they disappear from other program state sections as a result of any operation that isn't the actual dead symbol collection. The most common example here is: FILE *fp = fopen("myfile.txt", "w"); fp = 0; // leak of file descriptor In this example the leak were not detected previously because the symbol disappears from the public part of the program state due to evaluating the assignment. For that reason the checker never receives a notification that the symbol is dead, and never reports a leak. This patch not only causes leak false negatives, but also a number of other problems, including false positives on some checkers. What's worse, even though the program state contains a finite number of symbols, the set of symbols that dies is potentially infinite. This means that is impossible to compute the set of all dead symbols to pass off to the checkers for cleaning up their part of the GDM. No longer compute the dead set at all. Disallow iterating over dead symbols. Disallow querying if any symbols are dead. Remove the API for marking symbols as dead, as it is no longer necessary. Update checkers accordingly. Differential Revision: https://reviews.llvm.org/D18860 llvm-svn: 347953
* [analyzer] RetainCountChecker: recognize that OSObject can be created ↵George Karpenkov2018-11-301-0/+2
| | | | | | | | directly using an operator "new" Differential Revision: https://reviews.llvm.org/D55076 llvm-svn: 347949
* [analyzer] Switch retain count checker for OSObject to use OS_* attributesGeorge Karpenkov2018-11-301-1/+2
| | | | | | | | Instead of generalized reference counting annotations. Differential Revision: https://reviews.llvm.org/D55041 llvm-svn: 347948
* [analyzer] [NFC] Minor refactoring of RetainCountDiagnosticsGeorge Karpenkov2018-11-304-217/+252
| | | | | | | | | Move visitors to the implementation file, move a complicated logic into a function. Differential Revision: https://reviews.llvm.org/D55036 llvm-svn: 347946
* [analyzer] Print a fully qualified name for functions in RetainCountChecker ↵George Karpenkov2018-11-301-3/+12
| | | | | | | | | | | diagnostics Attempt to get a fully qualified name from AST if an SVal corresponding to the object is not available. Differential Revision: https://reviews.llvm.org/D55034 llvm-svn: 347944
* [analyzer] Add the type of the leaked object to the diagnostic messageGeorge Karpenkov2018-11-302-5/+22
| | | | | | | | | | | | If the object is a temporary, and there is no variable it binds to, let's at least print out the object name in order to help differentiate it from other temporaries. rdar://45175098 Differential Revision: https://reviews.llvm.org/D55033 llvm-svn: 347943
* [analyzer] Reference leaked object by name, even if it was created in an ↵George Karpenkov2018-11-301-15/+17
| | | | | | | | | | inlined function. rdar://45532181 Differential Revision: https://reviews.llvm.org/D54973 llvm-svn: 347942
* [analyzer] [NFC] Some miscellaneous clean ups and documentation fixes.George Karpenkov2018-11-301-87/+90
| | | | | | Differential Revision: https://reviews.llvm.org/D54971 llvm-svn: 347940
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-284-9/+15
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-274-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* [analyzer] INT50-CPP. Do not cast to an out-of-range enumeration checkerKristof Umann2018-11-242-0/+129
| | | | | | | | | | | | | | | This checker implements a solution to the "INT50-CPP. Do not cast to an out-of-range enumeration value" rule [1]. It lands in alpha for now, and a number of followup patches are planned in order to enable it by default. [1] https://www.securecoding.cert.org/confluence/display/cplusplus/INT50-CPP.+Do+not+cast+to+an+out-of-range+enumeration+value Patch by: Endre Fülöp and Alexander Zaitsev! Differential Revision: https://reviews.llvm.org/D33672 llvm-svn: 347513
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-214-9/+15
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-214-15/+9
| | | | llvm-svn: 347389
OpenPOWER on IntegriCloud