summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] ObjCContainers: Track index values.Artem Dergachev2018-12-151-9/+30
| | | | | | | | | | | | 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-5/+29
| | | | | | | | | | | | | | | | | | | 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
* Revert "Add extension to always default-initialize nullptr_t."Erich Keane2018-12-141-6/+11
| | | | | | | | | This reverts commit 46efdf2ccc2a80aefebf8433dbf9c7c959f6e629. Richard Smith commented just after I submitted this that this is the wrong solution. Reverting so that I can fix differently. llvm-svn: 349206
* Add extension to always default-initialize nullptr_t.Erich Keane2018-12-141-11/+6
| | | | | | | | | | | | | | | | | Core issue 1013 suggests that having an uninitialied std::nullptr_t be UB is a bit foolish, since there is only a single valid value. This DR reports that DR616 fixes it, which does so by making lvalue-to-rvalue conversions from nullptr_t be equal to nullptr. However, just implementing that results in warnings/etc in many places. In order to fix all situations where nullptr_t would seem uninitialized, this patch instead (as an otherwise transparent extension) default initializes uninitialized VarDecls of nullptr_t. Differential Revision: https://reviews.llvm.org/D53713 Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885 llvm-svn: 349201
* [analyzer] MoveChecker Pt.6: Suppress the warning for the move-safe STL classes.Artem Dergachev2018-12-143-43/+47
| | | | | | | | | | | 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-5/+44
| | | | | | | | | | | | | | | | | 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-142-29/+51
| | | | | | | | | | | | | 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] RunLoopAutoreleaseLeakChecker: Come up with a test for r348822.Artem Dergachev2018-12-131-6/+43
| | | | | | | | | | | | | Statement memoization was removed in r348822 because it was noticed to cause memory corruption. This was happening because a reference to an object in a DenseMap was used after being invalidated by inserting a new key into the map. This test case crashes reliably under ASan (i.e., when Clang is built with -DLLVM_USE_SANITIZER="Address") on at least some machines before r348822 and doesn't crash after it. llvm-svn: 349000
* Change CallGraph print to show the fully qualified nameErich Keane2018-12-121-5/+6
| | | | | | | | | | CallGraph previously would just show the normal name of a function, which gets really confusing when using it on large C++ projects. This patch switches the printName call to a printQualifiedName, so that the namespaces are included. Change-Id: Ie086d863f6b2251be92109ea1b0946825b28b49a llvm-svn: 348950
* Make clang::CallGraph look into template instantiationsErich Keane2018-12-121-1/+20
| | | | | | | | | Clang's CallGraph analysis doesn't use the RecursiveASTVisitor's setting togo into template instantiations. The result is that anything wanting to do call graph analysis ends up missing any template function calls. Change-Id: Ib4af44ed59f15d43f37af91622a203146a3c3189 llvm-svn: 348942
* [analyzer][CStringChecker] evaluate explicit_bzeroDavid Carlier2018-12-111-1/+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] Hack for backwards compatibility for options for RetainCountChecker.George Karpenkov2018-12-111-0/+1
| | | | | | To be removed once the clients update. llvm-svn: 348821
* [analyzer] Display a diagnostics when an inlined function violates its ↵George Karpenkov2018-12-111-1/+27
| | | | | | | | | | | | | 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-2/+2
| | | | | | | | printed properly Differential Revision: https://reviews.llvm.org/D55528 llvm-svn: 348819
* Stop tracking retain count of OSObject after escape to void * / other ↵George Karpenkov2018-12-081-0/+7
| | | | | | | | | | | | | | 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-1/+38
| | | | | | | | | 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
* [CTU] test/Analysis/ctu-main.cpp Attempt to fix failing windows botGabor Marton2018-12-071-2/+2
| | | | llvm-svn: 348614
* [CTU] Add triple/lang mismatch handlingGabor Marton2018-12-072-0/+42
| | | | | | | | | | | | | | | | | | Summary: We introduce a strict policy for C++ CTU. It can work across TUs only if the C++ dialects are the same. We neither allow C vs C++ CTU. We do this because the same constructs might be represented with different properties in the corresponding AST nodes or even the nodes might be completely different (a struct will be RecordDecl in C, but it will be a CXXRectordDecl in C++, thus it may cause certain assertions during cast operations). Reviewers: xazax.hun, a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Differential Revision: https://reviews.llvm.org/D55134 llvm-svn: 348610
* [CTU] test/Analysis/ctu-main.cpp Attempt to fix failing windows botGabor Marton2018-12-071-2/+2
| | | | llvm-svn: 348609
* [CTU] Add more lit tests and better error handlingGabor Marton2018-12-075-1/+123
| | | | | | | | | | | | | | | Summary: Adding some more CTU list tests. E.g. to check if a construct is unsupported. We also slightly modify the handling of the return value of the `Import` function from ASTImporter. Reviewers: xazax.hun, balazske, a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Differential Revision: https://reviews.llvm.org/D55131 llvm-svn: 348605
* [CTU] Add DisplayCTUProgress analyzer switchGabor Marton2018-12-072-1/+10
| | | | | | | | | | | | | | | | 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
* [CTU] Eliminate race condition in CTU lit testsGabor Marton2018-12-071-5/+12
| | | | | | | | | | | | | | | Summary: We plan to introduce additional CTU related lit test. Since lit may run the tests in parallel, it is not safe to use the same directory (%T) for these tests. It is safe to use however test case specific directories (%t). Reviewers: xazax.hun, a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Differential Revision: https://reviews.llvm.org/D55129 llvm-svn: 348587
* [analyzer] Rely on os_consumes_this attribute to signify that the method ↵George Karpenkov2018-12-061-0/+16
| | | | | | | | 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-0/+12
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D55351 llvm-svn: 348531
* [analyzer] Attribute for RetainCountChecker for OSObject should propagate ↵George Karpenkov2018-12-051-3/+35
| | | | | | | | | | 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-34/+33
| | | | | | | | | | | | | | | | | | | | 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-0/+37
| | | | | | | | | | | | | | | | | | 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-0/+10
| | | | | | | | | 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-71/+71
| | | | | | | | | | | | | | | | | | | 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-15/+86
| | | | | | | | | | | | | | | | | | | | | | | | 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-0/+12
| | | | | | | | | | | | | | | | | | 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-031-2/+6
| | | | | | | | | 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-3/+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
* Re-apply r347954 "[analyzer] Nullability: Don't detect post factum violation..."Artem Dergachev2018-12-032-2/+72
| | | | | | | | | | | 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
* [Analysis] Properly prepare test env in test/Analysis/undef-call.cIlya Biryukov2018-12-031-0/+2
| | | | | | The test expectes the '%T/ctudir' to be present, but does not create it. llvm-svn: 348124
* Specify constant context in constant emitterBill Wendling2018-12-011-3/+3
| | | | | | | The constant emitter may need to evaluate the expression in a constant context. For exasmple, global initializer lists. llvm-svn: 348070
* [analyzer] Deleting unnecessary test fileKristof Umann2018-11-301-54/+0
| | | | | | That I really should've done in rC348031. llvm-svn: 348044
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-3/+3
| | | | | | | | | | 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] Emit an error for invalid -analyzer-config inputsKristof Umann2018-11-301-0/+71
| | | | | | Differential Revision: https://reviews.llvm.org/D53280 llvm-svn: 348038
* [analyzer] Evaluate all non-checker config options before analysisKristof Umann2018-11-302-28/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+34
| | | | | | | | 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-302-68/+422
| | | | | | | | | 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-32/+0
| | | | | | 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
* lyzer] [HOTFIX!] SValBuilder crash when ↵Adam Balogh2018-11-301-0/+17
| | | | | | | | | | | | | `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
* Revert r344580 "[analyzer] Nullability: Don't detect post factum violation..."Artem Dergachev2018-11-302-72/+2
| | | | | | Fails under ASan! llvm-svn: 347956
* [analyzer] Nullability: Don't detect post factum violation on concrete values.Artem Dergachev2018-11-302-2/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fixes after rebase.George Karpenkov2018-11-301-5/+5
| | | | llvm-svn: 347951
* [analyzer] RetainCountChecker for OSObject model the "free" callGeorge Karpenkov2018-11-301-0/+17
| | | | | | | | | The "free" call frees the object immediately, ignoring the reference count. Sadly, it is actually used in a few places, so we need to model it. Differential Revision: https://reviews.llvm.org/D55092 llvm-svn: 347950
* [analyzer] RetainCountChecker: recognize that OSObject can be created ↵George Karpenkov2018-11-301-0/+15
| | | | | | | | directly using an operator "new" Differential Revision: https://reviews.llvm.org/D55076 llvm-svn: 347949
OpenPOWER on IntegriCloud