summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Replace isIntegerType() with isIntegerOrEnumerationType().Jordan Rose2013-04-0912-26/+31
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, the analyzer used isIntegerType() everywhere, which uses the C definition of "integer". The C++ predicate with the same behavior is isIntegerOrUnscopedEnumerationType(). However, the analyzer is /really/ using this to ask if it's some sort of "integrally representable" type, i.e. it should include C++11 scoped enumerations as well. hasIntegerRepresentation() sounds like the right predicate, but that includes vectors, which the analyzer represents by its elements. This commit audits all uses of isIntegerType() and replaces them with the general isIntegerOrEnumerationType(), except in some specific cases where it makes sense to exclude scoped enumerations, or any enumerations. These cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>() plus BuiltinType::isInteger(). isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and include/clang/StaticAnalysis. :-) Fixes real assertion failures. PR15703 / <rdar://problem/12350701> llvm-svn: 179081
* [analyzer] Keep tracking the pointer after the escape to more aggressively ↵Anna Zaks2013-04-091-30/+43
| | | | | | | | | | | report mismatched deallocator Test that the path notes do not change. I don’t think we should print a note on escape. Also, I’ve removed a check that assumed that the family stored in the RefStete could be AF_None and added an assert in the constructor. llvm-svn: 179075
* Tweak warning text for nil value in ObjC container warning.Ted Kremenek2013-04-081-1/+1
| | | | llvm-svn: 179034
* [analyzer] When creating a trimmed graph, preserve whether a node is a sink.Jordan Rose2013-04-061-1/+2
| | | | | | | | | | | | | | This is important because sometimes two nodes are identical, except the second one is a sink. This bug has probably been around for a while, but it wouldn't have been an issue in the old report graph algorithm. I'm ashamed to say I actually looked at this the first time around and thought it would never be a problem...and then didn't include an assertion to back that up. PR15684 llvm-svn: 178944
* [analyzer] Shorten the malloc checker’s leak messageAnna Zaks2013-04-061-2/+3
| | | | | | As per Ted’s suggestion! llvm-svn: 178938
* [analyzer] Reword error messages for nil keys and values of NSMutableDictionary.Anna Zaks2013-04-051-6/+17
| | | | llvm-svn: 178935
* [analyzer] Remove another redundancy from trackNullOrUndefAnna Zaks2013-04-051-6/+0
| | | | llvm-svn: 178934
* [analyzer] Fix null tracking for the given test case, by using the proper ↵Anna Zaks2013-04-051-18/+3
| | | | | | state and removing redundant code. llvm-svn: 178933
* [analyzer] Eliminates all the cases with unknown family.Anton Yartsev2013-04-051-6/+7
| | | | | | Now treat AF_None family as impossible in isTrackedFamily() llvm-svn: 178899
* [analyzer] Re-enable cplusplus.NewDelete (but not NewDeleteLeaks).Jordan Rose2013-04-051-4/+5
| | | | | | | | As mentioned in the previous commit message, the use-after-free and double-free warnings for 'delete' are worth enabling even while the leak warnings still have false positives. llvm-svn: 178891
* [analyzer] Split new/delete checker into use-after-free and leaks parts.Jordan Rose2013-04-052-3/+18
| | | | | | | | | | | | This splits the leak-checking part of alpha.cplusplus.NewDelete into a separate user-level checker, alpha.cplusplus.NewDeleteLeaks. All the difficult false positives we've seen with the new/delete checker have been spurious leak warnings; the use-after-free warnings and mismatched deallocator warnings, while rare, have always been valid. <rdar://problem/6194569> llvm-svn: 178890
* [analyzer] Path notes for the MismatchedDeallocator checker.Anton Yartsev2013-04-051-4/+8
| | | | llvm-svn: 178862
* [analyzer] Check allocation family more precise.Anton Yartsev2013-04-051-4/+4
| | | | | | | | | The statement passed to isTrackedFamily() might be a user defined function calling malloc; in this case we got AF_NONE family for this function. Now the allocation family is derived from Sym, that holds a family of a real allocator. This commit is also a movement towards getting rid of tracking memory allocating by unknown means. llvm-svn: 178834
* [analyzer] Corrected the switch statement.Anton Yartsev2013-04-051-6/+3
| | | | llvm-svn: 178831
* [analyzer] Show path diagnostic for C++ initializersAnna Zaks2013-04-053-2/+17
| | | | | | Also had to modify the PostInitializer ProgramLocation to contain the field region. llvm-svn: 178826
* [analyzer] Fully-covered switch for families in isTrackedFamily()Anton Yartsev2013-04-051-7/+18
| | | | llvm-svn: 178820
* [analyzer] Reduced the unwanted correlations between checkers living inside ↵Anton Yartsev2013-04-041-89/+137
| | | | | | | | | | | | | MallocChecker.cpp This fixes an issue pointed to by Jordan: if unix.Malloc and unix.MismatchedDeallocator are both on, then we end up still tracking leaks of memory allocated by new. Moved the guards right before emitting the bug reports to unify and simplify the logic of handling of multiple checkers. Now all the checkers perform their checks regardless of if they were enabled, or not, and it is decided just before the emitting of the report, if it should be emitted. (idea from Anna). Additional changes: improved test coverage for checker correlations; refactoring: BadDealloc -> MismatchedDealloc llvm-svn: 178814
* [analyzer] Enable destructor inlining by default (c++-inlining=destructors).Jordan Rose2013-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | This turns on not only destructor inlining, but inlining of constructors for types with non-trivial destructors. Per r178516, we will still not inline the constructor or destructor of anything that looks like a container unless the analyzer-config option 'c++-container-inlining' is set to 'true'. In addition to the more precise path-sensitive model, this allows us to catch simple smart pointer issues: #include <memory> void test() { std::auto_ptr<int> releaser(new int[4]); } // memory allocated with 'new[]' should not be deleted with 'delete' <rdar://problem/12295363> llvm-svn: 178805
* [analyzer] RetainCountChecker: refactor annotation handling.Jordan Rose2013-04-041-63/+41
| | | | | | | | | ...and add a new test case. I thought this was broken, but it isn't; refactoring and reformatting anyway so that I don't make the same mistake again. No functionality change. llvm-svn: 178799
* [analyzer] Allow tracknullOrUndef look through the ternary operator even ↵Anna Zaks2013-04-031-13/+17
| | | | | | | | | | | | | when condition is unknown Improvement of r178684 and r178685. Jordan has pointed out that I should not rely on the value of the condition to know which expression branch has been taken. It will not work in cases the branch condition is an unknown value (ex: we do not track the constraints for floats). The better way of doing this would be to find out if the current node is the right or left successor of the node that has the ternary operator as a terminator (which is how this is done in other places, like ConditionBRVisitor). llvm-svn: 178701
* [analyzer] Correctly handle destructors for lifetime-extended temporaries.Jordan Rose2013-04-031-14/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | The lifetime of a temporary can be extended when it is immediately bound to a local reference: const Value &MyVal = Value("temporary"); In this case, the temporary object's lifetime is extended for the entire scope of the reference; at the end of the scope it is destroyed. The analyzer was modeling this improperly in two ways: - Since we don't model temporary constructors just yet, we create a fake temporary region when it comes time to "materialize" a temporary into a real object (lvalue). This wasn't taking base casts into account when the bindings being materialized was Unknown; now it always respects base casts except when the temporary region is itself a pointer. - When actually destroying the region, the analyzer did not actually load from the reference variable -- it was basically destroying the reference instead of its referent. Now it does do the load. This will be more useful whenever we finally start modeling temporaries, or at least those that get bound to local reference variables. <rdar://problem/13552274> llvm-svn: 178697
* [analyzer] Rename “Mac OS X API”, “Mac OS API” -> “API Misuse ↵Anna Zaks2013-04-033-4/+5
| | | | | | | | (Apple)” As they are relevant on both Mac and iOS. llvm-svn: 178687
* [analyzer] Warn when nil receiver results in forming null referenceAnna Zaks2013-04-031-12/+19
| | | | | | This also allows us to ensure IDC/return null suppression gets triggered in such cases. llvm-svn: 178686
* [analyzer] make peelOffOuterExpr in BugReporterVisitors recursively peel off ↵Anna Zaks2013-04-031-30/+31
| | | | | | select Exprs llvm-svn: 178685
* [analyzer] Properly handle the ternary operator in trackNullOrUndefValueAnna Zaks2013-04-032-11/+22
| | | | | | | | | | | | 1) Look for the node where the condition expression is live when checking if it is constrained to true or false. 2) Fix a bug in ProgramState::isNull, which was masking the problem. When the expression is not a symbol (,which is the case when it is Unknown) return unconstrained value, instead of value constrained to “false”! (Thankfully other callers of isNull have not been effected by the bug.) llvm-svn: 178684
* [analyzer] Fix typo.Anna Zaks2013-04-031-1/+1
| | | | | | Thanks Jordan! llvm-svn: 178683
* [analyzer] Better model for copying of array fields in implicit copy ctors.Jordan Rose2013-04-034-38/+95
| | | | | | | | | | | | - Find the correct region to represent the first array element when constructing a CXXConstructorCall. - If the array is trivial, model the copy with a primitive load/store. - Don't warn about the "uninitialized" subscript in the AST -- we don't use the helper variable that Sema provides. <rdar://problem/13091608> llvm-svn: 178602
* Silencing warnings in MSVC due to duplicate identifiers.Aaron Ballman2013-04-021-2/+2
| | | | llvm-svn: 178591
* [analyzer] Moving cplusplus.NewDelete to alpha.* for now.Anton Yartsev2013-04-021-5/+4
| | | | llvm-svn: 178529
* [analyzer] Teach invalidateRegions that regions within LazyCompoundVal need ↵Anna Zaks2013-04-023-54/+127
| | | | | | | | | | | | to be invalidated Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore about processing LazyCompoundVal as a top-level “escaping” value. This addresses several false positives that get triggered by the NewDelete checker, but the underlying issue is reproducible with other checkers as well (for example, MallocChecker). llvm-svn: 178518
* [analyzer] For now, don't inline [cd]tors of C++ containers.Jordan Rose2013-04-022-4/+63
| | | | | | | | | | | | | | | | | | | | | This is a heuristic to make up for the fact that the analyzer doesn't model C++ containers very well. One example is modeling that 'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be nice to model this explicitly, but for now it just results in a lot of false positives. The actual heuristic checks if the base type has a member named 'begin' or 'iterator'. If so, we treat the constructors and destructors of that type as opaque, rather than inlining them. This is intended to drastically reduce the number of false positives reported with experimental destructor support turned on. We can tweak the heuristic in the future, but we'd rather err on the side of false negatives for now. <rdar://problem/13497258> llvm-svn: 178516
* [analyzer] Cache whether a function is generally inlineable.Jordan Rose2013-04-021-52/+96
| | | | | | | | | | | | | | | Certain properties of a function can determine ahead of time whether or not the function is inlineable, such as its kind, its signature, or its location. We can cache this value in the FunctionSummaries map to avoid rechecking these static properties for every call. Note that the analyzer may still decide not to inline a specific call to a function because of the particular dynamic properties of the call along the current path. No intended functionality change. llvm-svn: 178515
* [analyzer] Use inline storage in the FunctionSummary DenseMap.Jordan Rose2013-04-021-10/+4
| | | | | | | | | | | | | The summaries lasted for the lifetime of the map anyway; no reason to include an extra allocation. Also, use SmallBitVector instead of BitVector to track the visited basic blocks -- most functions will have less than 64 basic blocks -- and use bitfields for the other fields to reduce the size of the structure. No functionality change. llvm-svn: 178514
* [analyzer] Allow suppressing diagnostics reported within the 'std' namespaceJordan Rose2013-04-022-7/+38
| | | | | | | | | | | | This is controlled by the 'suppress-c++-stdlib' analyzer-config flag. It is currently off by default. This is more suppression than we'd like to do, since obviously there can be user-caused issues within 'std', but it gives us the option to wield a large hammer to suppress false positives the user likely can't work around. llvm-svn: 178513
* [analyzer] Restructure ExprEngine::VisitCXXNewExpr to do a bit less work.Jordan Rose2013-03-301-10/+11
| | | | | | No functionality change. llvm-svn: 178402
* [analyzer] Handle caching out while evaluating a C++ new expression.Jordan Rose2013-03-301-3/+4
| | | | | | | | | | | | | Evaluating a C++ new expression now includes generating an intermediate ExplodedNode, and this node could very well represent a previously- reachable state in the ExplodedGraph. If so, we can short-circuit the rest of the evaluation. Caught by the assertion a few lines later. <rdar://problem/13510065> llvm-svn: 178401
* [analyzer] Address Jordan’s review of r178309 - do not register an extra ↵Anna Zaks2013-03-291-20/+19
| | | | | | | | | | | | visitor for nil receiver We can check if the receiver is nil in the node that corresponds to the StmtPoint of the message send. At that point, the receiver is guaranteed to be live. We will find at least one unreclaimed node due to my previous commit (look for StmtPoint instead of PostStmt) and the fact that the nil receiver nodes are tagged. + a couple of extra tests. llvm-svn: 178381
* [analyzer] Look for a StmtPoint node instead of PostStmt in ↵Anna Zaks2013-03-291-1/+1
| | | | | | | | | | trackNullOrUndefValue. trackNullOrUndefValue tries to find the first node that matches the statement it is tracking. Since we collect PostStmt nodes (in node reclamation), none of those might be on the current path, so relax the search to look for any StmtPoint. llvm-svn: 178380
* Add static analyzer support for conditionally executing static initializers.Ted Kremenek2013-03-294-20/+47
| | | | llvm-svn: 178318
* Add configuration plumbing to enable static initializer branching in the CFG ↵Ted Kremenek2013-03-292-1/+7
| | | | | | | | | for the analyzer. This setting still isn't enabled yet in the analyzer. This is just prep work. llvm-svn: 178317
* [analyzer] Document existence of ConstPointerEscape.Anna Zaks2013-03-281-0/+12
| | | | llvm-svn: 178311
* [analyzer] Add support for escape of const pointers and use it to allow ↵Anna Zaks2013-03-285-28/+103
| | | | | | | | | | | | | “newed” pointers to escape Add a new callback that notifies checkers when a const pointer escapes. Currently, this only works for const pointers passed as a top level parameter into a function. We need to differentiate the const pointers escape from regular escape since the content pointed by const pointer will not change; if it’s a file handle, a file cannot be closed; but delete is allowed on const pointers. This should suppress several false positives reported by the NewDelete checker on llvm codebase. llvm-svn: 178310
* [analyzer] Apply the suppression rules to the nil receiver only if the value ↵Anna Zaks2013-03-283-40/+61
| | | | | | | | | | | | | | participates in the computation of the nil we warn about. We should only suppress a bug report if the IDCed or null returned nil value is directly related to the value we are warning about. This was not the case for nil receivers - we would suppress a bug report that had an IDCed nil receiver on the path regardless of how it’s related to the warning. 1) Thread EnableNullFPSuppression parameter through the visitors to differentiate between tracking the value which is directly responsible for the bug and other values that visitors are tracking (ex: general tracking of nil receivers). 2) in trackNullOrUndef specifically address the case when a value of the message send is nil due to the receiver being nil. llvm-svn: 178309
* Use early return in printing logic. Minor cleanup.Ted Kremenek2013-03-281-2/+4
| | | | llvm-svn: 178264
* Fix order of initialization warning.Eric Christopher2013-03-281-1/+1
| | | | llvm-svn: 178255
* [analyzer] These implements unix.MismatchedDeallocatorChecker checker.Anton Yartsev2013-03-282-75/+301
| | | | | | | | + Improved display names for allocators and deallocators The checker checks if a deallocation function matches allocation one. ('free' for 'malloc', 'delete' for 'new' etc.) llvm-svn: 178250
* [analyzer] For now assume all standard global 'operator new' functions ↵Anton Yartsev2013-03-282-8/+31
| | | | | | | | allocate memory in heap. + Improved test coverage for cplusplus.NewDelete checker. llvm-svn: 178244
* [analyzer] Use evalBind for C++ new of scalar types.Jordan Rose2013-03-271-7/+10
| | | | | | | | | | These types will not have a CXXConstructExpr to do the initialization for them. Previously we just used a simple call to ProgramState::bindLoc, but that doesn't trigger proper checker callbacks (like pointer escape). Found by Anton Yartsev. llvm-svn: 178160
* [analyzer] Cleanup: only get the PostStmt when we need the underlying Stmt + ↵Anna Zaks2013-03-271-4/+4
| | | | | | comment llvm-svn: 178153
* [analyzer] Ensure that the node NilReceiverBRVisitor is looking for is not ↵Anna Zaks2013-03-272-4/+5
| | | | | | | | | reclaimed The visitor should look for the PreStmt node as the receiver is nil in the PreStmt and this is the node. Also, tag the nil receiver nodes with a special tag for consistency. llvm-svn: 178152
OpenPOWER on IntegriCloud