summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
...
* [Analyzer] Mark `SymbolData` parts of iterator position as live in program ↵Adam Balogh2018-07-161-21/+33
| | | | | | | | | | | | | | state maps Marking a symbolic expression as live is non-recursive. In our checkers we either use conjured symbols or conjured symbols plus/minus integers to represent abstract position of iterators, so in this latter case we also must mark the `SymbolData` part of these symbolic expressions as live to prevent them from getting reaped. Differential Revision: https://reviews.llvm.org/D48764 llvm-svn: 337151
* [Analyzer] alpha.unix.cstring.OutOfBounds checker enable/disable fixAdam Balogh2018-07-131-6/+6
| | | | | | | | | | | | | | | | | | 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-18/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D48291 llvm-svn: 336995
* [analyzer][UninitializedObjectChecker] Support for MemberPointerTypesKristof Umann2018-07-131-29/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D48325 llvm-svn: 336994
* [analyzer][UninitializedObjectChecker] Moved non-member functions out of the ↵Kristof Umann2018-07-121-17/+17
| | | | | | | | | | | anonymous namespace As the code for the checker grew, it became increasinly difficult to see whether a function was global or statically defined. In this patch, anything that isn't a type declaration or definition was moved out of the anonymous namespace and is marked as static. llvm-svn: 336901
* [analyzer] Track multiple raw pointer symbols in DanglingInternalBufferChecker.Reka Kovacs2018-07-111-18/+50
| | | | | | | | | | | | 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] Partial revert of https://reviews.llvm.org/D49050George Karpenkov2018-07-111-8/+7
| | | | llvm-svn: 336755
* [analyzer] Pass through all arguments from the registerChecker() to the ↵George Karpenkov2018-07-111-7/+8
| | | | | | | | | | checker constructor A lot of checkers could be cleaned up in a similar way Differential Revision: https://reviews.llvm.org/D49050 llvm-svn: 336753
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-1/+5
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* [analyzer] Add option to set maximum symbol complexity thresholdMikhail R. Gadelha2018-07-102-1/+11
| | | | | | | | | | | | | | | | | | | Summary: This adds an option, max-symbol-complexity, so an user can set the maximum symbol complexity threshold. Note that the current behaviour is equivalent to max complexity = 0, when taint analysis is not enabled and tests show that in a number of tests, having complexity = 25 yields the same results as complexity = 10000. This patch was extracted and modified from Dominic Chen's patch, D35450. Reviewers: george.karpenkov, NoQ, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49093 llvm-svn: 336671
* [analyzer] Add support for data() in DanglingInternalBufferChecker.Reka Kovacs2018-07-071-5/+6
| | | | | | | | | 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-073-10/+88
| | | | | | | | | | 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] Fix -Wcovered-switch-default warning in MallocChecker.Reka Kovacs2018-07-071-1/+0
| | | | | | Remove unnecessary default case that caused buildbot failures. llvm-svn: 336493
* [analyzer] Highlight container object destruction in MallocChecker.Reka Kovacs2018-07-071-14/+46
| | | | | | | | | 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-041-3/+7
| | | | | | | | | | | | | | 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
* Factor out Clang's desired 8MB stack size constant from the variousRichard Smith2018-07-031-2/+2
| | | | | | places we hardcode it. llvm-svn: 336231
* [analyzer] Replace the vector of ConstraintSets by a single ConstraintSet ↵Mikhail R. Gadelha2018-06-291-15/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and a function to merge ConstraintSets Now, instead of adding the constraints when they are removed, this patch adds them when they first appear and, since we walk the bug report backward, it should be the last set of ranges generated by the CSA for a given symbol. These are the number before and after the patch: ``` Project | current | patch | tmux | 283.222 | 123.052 | redis | 614.858 | 400.347 | openssl | 308.292 | 307.149 | twin | 274.478 | 245.411 | git | 547.687 | 477.335 | postgresql | 2927.495 | 2002.526 | sqlite3 | 3264.305 | 1028.416 | ``` Major speedups in tmux and sqlite (less than half of the time), redis and postgresql were about 25% faster while the rest are basically the same. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: rnkovacs, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48565 llvm-svn: 336002
* [analyzer][UninitializedObjectChecker] Added a NotesAsWarnings flagKristof Umann2018-06-291-21/+53
| | | | | | | | | | 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 wrong comparison generation of the ranges generated by the ↵Mikhail R. Gadelha2018-06-281-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | refutation manager The refutation manager is removing a true bug from the test in this patch. The problem is that the following constraint: ``` (conj_$1{struct o *}) - (reg_$3<int * r>): [-9223372036854775808, 0] ``` is encoded as: ``` (and (bvuge (bvsub $1 $3) #x8000000000000000) (bvule (bvsub $1 $3) #x0000000000000000)) ``` The issue is that unsigned comparisons (bvuge and bvule) are being generated instead of signed comparisons (bvsge and bvsle). When generating the expressions: ``` (conj_$1{p *}) - (reg_$3<int * r>) >= -9223372036854775808 ``` and ``` (conj_$1{p *}) - (reg_$3<int * r>) <= 0 ``` both -9223372036854775808 and 0 are casted to pointer type and `LTy->isSignedIntegerOrEnumerationType()` in `Z3ConstraintManager::getZ3BinExpr` only checks if the type is signed, not if it's a pointer. Reviewers: NoQ, george.karpenkov, ddcc Subscribers: rnkovacs, NoQ, george.karpenkov, ddcc, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48324 llvm-svn: 335926
* [Analyzer] Iterator Checker - Part 2: Increment, decrement operators and ↵Adam Balogh2018-06-281-31/+448
| | | | | | | | | | | | | 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-281-1/+68
| | | | | | | | 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] Remove redundant ';'.Artem Dergachev2018-06-281-1/+1
| | | | | | Fixes a compiler warning. No functionan change intended. llvm-svn: 335808
* [analyzer] Use sufficiently large types for index bounds calculation.Artem Dergachev2018-06-282-3/+3
| | | | | | | | | | | | | | | | | 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-282-43/+150
| | | | | | | | | | | | | | | | 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-281-8/+1
| | | | | | | | | | | | | | 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-281-9/+7
| | | | | | | | | | | | | | | | 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-283-1/+12
| | | | | | | | | | | | | | | | 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
* Revert "[Analyzer] Moved RangeConstraintManager to header. NFC."Mikhail R. Gadelha2018-06-271-0/+83
| | | | | | | | This broke a number of bots. This reverts commit 5e1a89912d37a21c3b49ccf30600d7f498dffa9c. llvm-svn: 335752
* [analyzer] Allow registering custom statically-linked analyzer checkersAlexander Kornienko2018-06-272-6/+18
| | | | | | | | | | | | | | | | | | Summary: Add an extension point to allow registration of statically-linked Clang Static Analyzer checkers that are not a part of the Clang tree. This extension point employs the mechanism used when checkers are registered from dynamically loaded plugins. Reviewers: george.karpenkov, NoQ, xazax.hun, dcoughlin Reviewed By: george.karpenkov Subscribers: mgorny, mikhail.ramalho, rnkovacs, xazax.hun, szepet, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D45718 llvm-svn: 335740
* [Analyzer] Moved RangeConstraintManager to header. NFC.Mikhail R. Gadelha2018-06-271-83/+0
| | | | | | | | | | | | | | Summary: While at it, added a dump method to RangeSet. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48561 llvm-svn: 335726
* [analyzer] [NFC] A convenient getter for getting a current stack frameGeorge Karpenkov2018-06-2719-66/+61
| | | | | | Differential Revision: https://reviews.llvm.org/D44756 llvm-svn: 335701
* [analyzer] Minor cleanups for BugReporter, expose a getter for AnalyzerOptions.George Karpenkov2018-06-261-10/+4
| | | | llvm-svn: 335683
* [analyzer] Do not run visitors until the fixpoint, run only once.George Karpenkov2018-06-2616-336/+354
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | | 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-2/+7
| | | | | | | | | | | | | | | | | | 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
* Add const qualifier on FieldChainInfoComparator::operator()Steven Wu2018-06-221-1/+1
| | | | | | | libcxx has user defined warning to check for non const call operator. Silence the warning by adding the const on operator(). llvm-svn: 335366
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* [analyzer] Optimize constraint generation when the range is a concrete valueMikhail R. Gadelha2018-06-201-52/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a constraint is something like: ``` $0 = [1,1] ``` it'll now be created as: ``` assert($0 == 1) ``` instead of: ``` assert($0 >= 1 && $0 <= 1) ``` In general, ~3% speedup when solving per query in my machine. Biggest improvement was when verifying sqlite3, total time went down from 3000s to 2200s. I couldn't create a test for this as there is no way to dump the formula yet. D48221 adds a method to dump the formula but there is no way to do it from the command line. Also, a test that prints the formula will most likely fail in the future, as different solvers print the formula in different formats. Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48227 llvm-svn: 335116
* [analyzer] Made a buildbot happy.Kristof Umann2018-06-191-7/+9
| | | | | | | Since `isPrimitiveType` was only used in an assert, a builbot with `-Werror` and no asserts enabled failed to build it as it was unused. llvm-svn: 335030
* [analyzer] Remove accidentally committed lines.George Karpenkov2018-06-181-4/+1
| | | | llvm-svn: 334965
* [analyzer] Checker for uninitialized C++ objectsKristof Umann2018-06-182-0/+670
| | | | | | | | | | | | | | | | | | 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] Add method to the generic SMT API to dump the SMT formulaMikhail R. Gadelha2018-06-161-0/+7
| | | | | | | | | | | | | | | | | | | Summary: New method dump the SMT formula and the Z3 implementation. There is no test because I only used it for debugging. However, if requested, I can add an option to the static analyzer to dump the formula (whole program? per path?), maybe something like the trimmed graph but for SMT formulas. Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48221 llvm-svn: 334891
* [analyzer] Re-enable C++17-specific RVO construction contexts.Artem Dergachev2018-06-141-16/+6
| | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | 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-142-60/+107
| | | | | | | | | | | | | | | 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-143-44/+9
| | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] NFC: Merge code for finding and tracking construction target.Artem Dergachev2018-06-143-128/+95
| | | | | | | | | | | | | | When analyzing C++ code, a common operation in the analyzer is to discover target region for object construction by looking at CFG metadata ("construction contexts"), and then track the region path-sensitively until object construction is resolved, where the amount of information, again, depends on construction context. Scan construction context only once for both purposes. Differential Revision: https://reviews.llvm.org/D47304 llvm-svn: 334678
* [analyzer] Fix offset overflow check in MemRegionGeorge Karpenkov2018-06-131-42/+8
| | | | | | | | | rdar://39593879 https://bugs.llvm.org/show_bug.cgi?id=37142 Differential Revision: https://reviews.llvm.org/D48139 llvm-svn: 334636
* Remove extraneous semicolon.Bill Wendling2018-06-131-1/+1
| | | | llvm-svn: 334573
* [analyzer] Do not crash in the visitor when the function is given more ↵George Karpenkov2018-06-121-1/+1
| | | | | | | | | | arguments than it has parameters rdar://40335545 Differential Revision: https://reviews.llvm.org/D48107 llvm-svn: 334560
OpenPOWER on IntegriCloud