summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Add a no-crash to a recently added test.Artem Dergachev2018-07-231-1/+1
| | | | | | No functional change intended. llvm-svn: 337776
* [analyzer] pr38273: Legalize Loc<>NonLoc comparison symbols.Artem Dergachev2018-07-231-0/+4
| | | | | | | | | Remove an assertion in RangeConstraintManager that expects such symbols to never appear, while admitting that the constraint manager doesn't yet handle them. Differential Revision: https://reviews.llvm.org/D49703 llvm-svn: 337769
* Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith2018-07-233-4/+4
| | | | | | checking. llvm-svn: 337743
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-231-6/+6
| | | | | | | This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
* [CStringSyntaxChecker] Improvements of strlcpy checkDavid Carlier2018-07-231-0/+1
| | | | | | | | | | | | Adding an additional check whenwe offset fro the buffer base address. Reviewers: george.karpenkov,NoQ Reviewed By: george.karpenkov Differential Revision: https://reviews.llvm.org/D49633 llvm-svn: 337721
* Fix for last commit: adding new test file forgotten.Adam Balogh2018-07-231-0/+43
| | | | llvm-svn: 337679
* [Analyzer] Quick Fix for exponential execution time when simpilifying ↵Adam Balogh2018-07-234-4/+67
| | | | | | | | | | | | | | | | | | complex additive expressions Patch https://reviews.llvm.org/rC329780 not only rearranges comparisons but also binary expressions. This latter behavior is not protected by the analyzer option. Hower, since no complexity threshold is enforced to the symbols this may result in exponential execution time if the expressions are too complex: https://bugs.llvm.org/show_bug.cgi?id=38208. For a quick fix we extended the analyzer option to also cover the additive cases. This is only a temporary fix, the final solution should be enforcing the complexity threshold to the symbols. Differential Revision: https://reviews.llvm.org/D49536 llvm-svn: 337678
* Revert "Fold dangling-field warning into general initialization lifetime ↵Ilya Biryukov2018-07-231-6/+6
| | | | | | | | | | | | | | | | checks." This reverts commit r337627. After the change, clang started producing invalid warning on the following code: struct foo { foo(char *x) : x_(&x[10]) {} private: char *x_; }; 1.cpp:2:21: warning: initializing pointer member 'x_' with the stack address of parameter 'x' [-Wdangling-field] llvm-svn: 337671
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-201-6/+6
| | | | llvm-svn: 337627
* [CStringSyntaxChecker] Fix build bot builds != x86 archsDavid Carlier2018-07-201-0/+4
| | | | | | | | | | Reviewers: NoQ,george.karpenkov Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D49588 llvm-svn: 337611
* [analyzer] Rename DanglingInternalBufferChecker to InnerPointerChecker.Reka Kovacs2018-07-201-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D49553 llvm-svn: 337559
* [CStringSyntaxChecker] Check strlcpy sizeof syntaxDavid Carlier2018-07-192-1/+16
| | | | | | | | | | | | | | | | | The last argument is expected to be the destination buffer size (or less). Detects if it points to destination buffer size directly or via a variable. Detects if it is an integral, try to detect if the destination buffer can receive the source length. Updating bsd-string.c unit tests as it make it fails now. Reviewers: george.karpenpov, NoQ Reviewed By: george.karpenkov Differential Revision: https://reviews.llvm.org/D48884 llvm-svn: 337499
* [analyzer] Add support for more basic_string API inReka Kovacs2018-07-191-60/+200
| | | | | | | | | | | | | DanglingInternalBufferChecker. A pointer referring to the elements of a basic_string may be invalidated by calling a non-const member function, except operator[], at, front, back, begin, rbegin, end, and rend. The checker now warns if the pointer is used after such operations. Differential Revision: https://reviews.llvm.org/D49360 llvm-svn: 337463
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-23/+0
| | | | | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. This reinstates r337226, reverted in r337255, with a fix for the InitializedEntity alignment problem that was breaking ARM buildbots. llvm-svn: 337329
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-171-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | lifetime extension." This change breaks on ARM because pointers to clang::InitializedEntity are only 4 byte aligned and do not have 3 bits to store values. A possible solution would be to change the fields in clang::InitializedEntity to enforce a bigger alignment requirement. The error message is llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer" static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here Value = Info::updateInt(Info::updatePointer(0, PtrVal), llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here setPointerAndInt(PtrVal, IntVal); ^ llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here return {Entity, LK_Extended}; Full log here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330 http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394 llvm-svn: 337255
* [analyzer] Fix size_t in tests.Artem Dergachev2018-07-171-1/+2
| | | | | | Should fix a buildbot. No functional change intended. llvm-svn: 337231
* [CFG] [analyzer] Allow elidable copies to have more than one arguments.Artem Dergachev2018-07-171-0/+23
| | | | | | | | | | Copy-constructors and move-constructors may have default arguments. It is incorrect to assert that they only have one argument, i.e. the reference to the object being copied or moved. Remove the assertion. Differential Revision: https://reviews.llvm.org/D49215 llvm-svn: 337229
* [analyzer] pr37802: Fix symbolic-pointer-to-boolean casts during load.Artem Dergachev2018-07-172-0/+112
| | | | | | | | | The canonical representation of pointer &SymRegion{$x} casted to boolean is "$x != 0", not "$x". Assertion added in r337227 catches that. Differential Revision: https://reviews.llvm.org/D48232 llvm-svn: 337228
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-23/+0
| | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. llvm-svn: 337226
* [analyzer] Bugfix for an overly eager suppression for null pointer return ↵George Karpenkov2018-07-161-0/+23
| | | | | | | | | | | | | from macros. Only suppress those cases where the null which came from the macro is relevant to the bug, and was not overwritten in between. rdar://41497323 Differential Revision: https://reviews.llvm.org/D48856 llvm-svn: 337213
* [analyzer] Fix GCDAntipatternChecker to only fire when the semaphore is ↵George Karpenkov2018-07-161-0/+10
| | | | | | | | | | | | initialized to zero Initializing a semaphore with a different constant most likely signals a different intent rdar://41802552 Differential Revision: https://reviews.llvm.org/D48911 llvm-svn: 337212
* [analyzer] Fix constraint being dropped when analyzing a program without ↵Mikhail R. Gadelha2018-07-164-24/+22
| | | | | | | | | | | | | | | | | | | | | | | taint tracking enabled Summary: This patch removes the constraint dropping when taint tracking is disabled. It also voids the crash reported in D28953 by treating a SymSymExpr with non pointer symbols as an opaque expression. Updated the regressions and verifying the big projects now; I'll update here when they're done. Based on the discussion on the mailing list and the patches by @ddcc. Reviewers: george.karpenkov, NoQ, ddcc, baloghadamsoftware Reviewed By: george.karpenkov Subscribers: delcypher, llvm-commits, rnkovacs, xazax.hun, szepet, a.sidorin, ddcc Differential Revision: https://reviews.llvm.org/D48650 llvm-svn: 337167
* [Analyzer] alpha.unix.cstring.OutOfBounds checker enable/disable fixAdam Balogh2018-07-133-17/+53
| | | | | | | | | | | | | | | | | | It was not possible to disable alpha.unix.cstring.OutOfBounds checker's reports since unix.Malloc checker always implicitly enabled the filter. Moreover if the checker was disabled from command line (-analyzer-disable-checker ..) the out of bounds warnings were nevertheless emitted under different checker names such as unix.cstring.NullArg, or unix.Malloc. This patch fixes the case sot that Malloc checker only enables implicitly the underlying modeling of strcpy, memcpy etc. but not the warning messages that would have been emmitted by alpha.unix.cstring.OutOfBounds Patch by: Dániel Krupp Differential Revision: https://reviews.llvm.org/D48831 llvm-svn: 337000
* [analyzer][UninitializedObjectChecker] Fixed captured lambda variable nameKristof Umann2018-07-131-3/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D48291 llvm-svn: 336995
* [analyzer][UninitializedObjectChecker] Support for MemberPointerTypesKristof Umann2018-07-131-8/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D48325 llvm-svn: 336994
* [analyzer] Track multiple raw pointer symbols in DanglingInternalBufferChecker.Reka Kovacs2018-07-111-0/+24
| | | | | | | | | | | | Previously, the checker only tracked one raw pointer symbol for each container object. But member functions returning a pointer to the object's inner buffer may be called on the object several times. These pointer symbols are now collected in a set inside the program state map and thus all of them is checked for use-after-free problems. Differential Revision: https://reviews.llvm.org/D49057 llvm-svn: 336835
* [analyzer] Fix bots by changing the analyzer-config tests.George Karpenkov2018-07-112-4/+2
| | | | | | To be investigated. llvm-svn: 336756
* [analyzer] Add support for data() in DanglingInternalBufferChecker.Reka Kovacs2018-07-071-9/+53
| | | | | | | | | DanglingInternalBufferChecker now tracks use-after-free problems related to the incorrect usage of std::basic_string::data(). Differential Revision: https://reviews.llvm.org/D48532 llvm-svn: 336497
* [analyzer] Highlight c_str() call in DanglingInternalBufferChecker.Reka Kovacs2018-07-071-5/+17
| | | | | | | | | | Add a bug visitor to DanglingInternalBufferChecker that places a note at the point where the dangling pointer was obtained. The visitor is handed over to MallocChecker and attached to the report there. Differential Revision: https://reviews.llvm.org/D48522 llvm-svn: 336495
* [analyzer] Highlight container object destruction in MallocChecker.Reka Kovacs2018-07-071-4/+4
| | | | | | | | | Extend MallocBugVisitor to place a note at the point where objects with AF_InternalBuffer allocation family are destroyed. Differential Revision: https://reviews.llvm.org/D48521 llvm-svn: 336489
* [analyzer][ctu] fix unsortable diagnosticsRafael Stahl2018-07-044-0/+18
| | | | | | | | | | | | | | Summary: In the provided test case the PathDiagnostic compare function was not able to find a difference. Reviewers: xazax.hun, NoQ, dcoughlin, george.karpenkov Reviewed By: george.karpenkov Subscribers: a_sidorin, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Differential Revision: https://reviews.llvm.org/D48474 llvm-svn: 336275
* [analyzer][UninitializedObjectChecker] Added a NotesAsWarnings flagKristof Umann2018-06-291-0/+15
| | | | | | | | | | In order to better support consumers of the plist output that don't parse note entries just yet, a 'NotesAsWarnings' flag was added. If it's set to true, all notes will be converted to warnings. Differential Revision: https://reviews.llvm.org/D48285 llvm-svn: 335964
* [analyzer] fix test case expected warningMikhail R. Gadelha2018-06-281-8/+0
| | | | | | | | | After r335814, the constraint manager is no longer generating a false bug report about the division by zero in the test case. This patch removes the expected false bug report. llvm-svn: 335932
* [analyzer] Move test to the correct directoryMikhail R. Gadelha2018-06-281-0/+24
| | | | | | It was accidentaly pushed in r335926 llvm-svn: 335929
* [Analyzer] Iterator Checker - Part 2: Increment, decrement operators and ↵Adam Balogh2018-06-283-3/+130
| | | | | | | | | | | | | ahead-of-begin checks Add handling of the begin() funcion of containers to the iterator checkers, together with the pre- and postfix ++ and -- operators of the iterators. This makes possible the checking of iterators dereferenced ahead of the begin of the container. Differential Revision: https://reviews.llvm.org/D32642 llvm-svn: 335835
* [Analyzer] Constraint Manager Negates DifferenceAdam Balogh2018-06-282-23/+98
| | | | | | | | If range [m .. n] is stored for symbolic expression A - B, then we can deduce the range for B - A which is [-n .. -m]. This is only true for signed types, unless the range is [0 .. 0]. Differential Revision: https://reviews.llvm.org/D35110 llvm-svn: 335814
* [analyzer] Use sufficiently large types for index bounds calculation.Artem Dergachev2018-06-281-2/+21
| | | | | | | | | | | | | | | | | The ProgramState::assumeInBound() API is used by checkers to make an assumption that a certain array index is within the array's bounds (i.e. is greater than or equal to 0 and is less than the length of the array). When the type of the index was unspecified by the caller, it assumed that the type is 'int', which caused some indices and sizes to truncate during calculations. Use ArrayIndexTy by default instead, which is used by the analyzer to represent index types and is currently hardcoded to long long. Patch by Bevin Hansson! Differential Revision: https://reviews.llvm.org/D46944 llvm-svn: 335803
* [analyzer] Add support for pre-C++17 copy elision.Artem Dergachev2018-06-285-277/+114
| | | | | | | | | | | | | | | | r335795 adds copy elision information to CFG. This commit allows static analyzer to elide elidable copy constructors by constructing the objects that were previously subject to elidable copy directly in the target region of the copy. The chain of elided constructors may potentially be indefinitely long. This only happens when the object is being returned from a function which in turn is returned from another function, etc. NRVO is not supported yet. Differential Revision: https://reviews.llvm.org/D47671 llvm-svn: 335800
* [CFG] [analyzer] Simplify lifetime-extended temporary construction contexts.Artem Dergachev2018-06-283-17/+17
| | | | | | | | | | | | | | When a temporary object is materialized and through that obtain lifetime that is longer than the duration of the full-expression, it does not require a temporary object destructor; it will be destroyed in a different manner. Therefore it's not necessary to include CXXBindTemporaryExpr into the construction context for such temporary in the CFG only to make clients throw it away. Differential Revision: https://reviews.llvm.org/D47667 llvm-svn: 335798
* [analyzer] Re-enable lifetime extension for temporaries without destructors.Artem Dergachev2018-06-282-19/+27
| | | | | | | | | | | | | | | | When an object's class provides no destructor, it's less important to materialize that object properly because we don't have to model the destructor correctly, so previously we skipped the support for these syntax patterns. Additionally, fix support for construction contexts of "static temporaries" (temporaries that are lifetime-extended by static references) because it turned out that we only had tests for them without destructors, which caused us to regress when we re-introduced the construction context for such temporaries. Differential Revision: https://reviews.llvm.org/D47658 llvm-svn: 335796
* [CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.Artem Dergachev2018-06-284-47/+83
| | | | | | | | | | | | | | | | Before C++17 copy elision was optional, even if the elidable copy/move constructor had arbitrary side effects. The elidable constructor is present in the AST, but marked as elidable. In these cases CFG now contains additional information that allows its clients to figure out if a temporary object is only being constructed so that to pass it to an elidable constructor. If so, it includes a reference to the elidable constructor's construction context, so that the client could elide the elidable constructor and construct the object directly at its final destination. Differential Revision: https://reviews.llvm.org/D47616 llvm-svn: 335795
* [analyzer] [NFC] Add -verify to malloc checker testGeorge Karpenkov2018-06-271-19/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D48514 llvm-svn: 335700
* [analyzer] Do not run visitors until the fixpoint, run only once.George Karpenkov2018-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Track null and undef values through expressions with cleanups.Artem Dergachev2018-06-251-0/+17
| | | | | | | | | | | | | | | | | ExprWithCleanups wraps full-expressions that require temporary destructors and highlights the moment of time in which these destructors need to be called (i.e., "at the end of the full-expression..."). Such expressions don't necessarily return an object; they may return anything, including a null or undefined value. When the analyzer tries to understand where the null or undefined value came from in order to present better diagnostics to the user, it will now skip any ExprWithCleanups it encounters and look into the expression itself. Differential Revision: https://reviews.llvm.org/D48204 llvm-svn: 335559
* [analyzer] Fix invalidation on C++ const methods with arrow syntax.Artem Dergachev2018-06-251-0/+24
| | | | | | | | | | | | | | | | | | Conservative evaluation of a C++ method call would invalidate the object, as long as the method is not const or the object has mutable fields. When checking for mutable fields, we need to scan the type of the object on which the method is called, which may be more specific than the type of the object on which the method is defined, hence we look up the type from the this-argument expression. If arrow syntax or implicit-this syntax is used, this-argument expression has pointer type, not record type, and lookup accidentally failed for that reason. Obtain object type correctly. Differential Revision: https://reviews.llvm.org/D48460 llvm-svn: 335555
* [analyzer] Checker for uninitialized C++ objectsKristof Umann2018-06-184-0/+2550
| | | | | | | | | | | | | | | | | | This checker analyzes C++ constructor calls, and reports uninitialized fields. Due to the nature of this problem (uninitialized fields after an object construction), this checker doesn't search for bugs, but rather is a tool to enforce a specific programming model where every field needs to be initialized. This checker lands in alpha for now, and a number of followup patches will be made to reduce false negatives and to make it easier for the user to understand what rules the checker relies on, eg. whether a derived class' constructor is responsible for initializing inherited data members or whether it should be handled in the base class' constructor. Differential Revision: https://reviews.llvm.org/D45532 llvm-svn: 334935
* [analyzer] Re-enable C++17-specific RVO construction contexts.Artem Dergachev2018-06-141-2/+64
| | | | | | | | | | | | | | | | | | | Not contexts themselves, but rather support for them in the analyzer. Such construction contexts appear when C++17 mandatory copy elision occurs while returning an object from a function, and presence of a destructor causes a CXXBindTemporaryExpr to appear in the AST. Additionally, such construction contexts may be chained, because a return-value construction context doesn't really explain where the object is being returned into, but only points to the parent stack frame, where the object may be consumed by literally anything including another return statement. This behavior is now modeled correctly by the analyzer as long as the object is not returned beyond the boundaries of the analysis. Differential Revision: https://reviews.llvm.org/D47405 llvm-svn: 334684
* [analyzer] Re-enable C++17-specific variable and member construction contexts.Artem Dergachev2018-06-141-0/+119
| | | | | | | | | | | | | | Not contexts themselves, but rather support for them in the analyzer. Such construction contexts appear when C++17 mandatory copy elision occurs during initialization, and presence of a destructor causes a CXXBindTemporaryExpr to appear in the AST. Similar C++17-specific constructors for return values are still to be supported. Differential Revision: https://reviews.llvm.org/D47351 llvm-svn: 334683
* [analyzer] Track class member initializer constructors path-sensitively.Artem Dergachev2018-06-141-0/+31
| | | | | | | | | | | | | | | The reasoning behind this change is similar to the previous commit, r334681. Because members are already in scope when construction occurs, we are not suffering from liveness problems, but we still want to figure out if the object was constructed with construction context, because in this case we'll be able to avoid trivial copy, which we don't always model perfectly. It'd also have more importance when copy elision is implemented. This also gets rid of the old CFG look-behind mechanism. Differential Revision: https://reviews.llvm.org/D47350 llvm-svn: 334682
* [analyzer] pr37270: Track constructor target region, even if just a variable.Artem Dergachev2018-06-141-0/+22
| | | | | | | | | | | | | | | | | | | | | | The very idea of construction context implies that first the object is constructed, and then later, in a separate moment of time, the constructed object goes into scope, i.e. becomes "live". Most construction contexts require path-sensitive tracking of the constructed object region in order to compute the outer expressions accordingly before the object becomes live. Semantics of simple variable construction contexts don't immediately require that such tracking happens in path-sensitive manner, but shortcomings of the analyzer force us to track it path-sensitively as well. Namely, whether construction context was available at all during construction is a path-sensitive information. Additionally, path-sensitive tracking takes care of our liveness problems that kick in as the temporal gap between construction and going-into-scope becomes larger (eg., due to copy elision). Differential Revision: https://reviews.llvm.org/D47305 llvm-svn: 334681
OpenPOWER on IntegriCloud