summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Add ipa-always-inline-size option (with 3 as the default).Anna Zaks2012-09-102-7/+39
| | | | | | | | The option allows to always inline very small functions, whose size (in number of basic blocks) is set using -analyzer-config ipa-always-inline-size option. llvm-svn: 163558
* [analyzer] Make the defaults explicit for each of the new config options.Jordan Rose2012-09-101-2/+2
| | | | | | Also, document both new inlining options in IPA.txt. llvm-svn: 163551
* [analyzer] For now, don't inline C++ standard library functions.Jordan Rose2012-09-102-1/+61
| | | | | | | | | | | | | | | | This is a (heavy-handed) solution to PR13724 -- until we know we can do a good job inlining the STL, it's best to be consistent and not generate more false positives than we did before. We can selectively whitelist certain parts of the 'std' namespace that are known to be safe. This is controlled by analyzer config option 'c++-stdlib-inlining', which can be set to "true" or "false". This commit also adds control for whether or not to inline any templated functions (member or non-member), under the config option 'c++-template-inlining'. This option is currently on by default. llvm-svn: 163548
* Fix another case where we should be using isBeforeInTranslationUnit().Ted Kremenek2012-09-101-2/+4
| | | | llvm-svn: 163533
* Add a few more cases where we should be using isBeforeInTranslationUnit().Ted Kremenek2012-09-101-2/+4
| | | | llvm-svn: 163531
* Revert "Revert Ted's r163489 and r163490, due to breakage."Ted Kremenek2012-09-101-11/+135
| | | | | | | | | I need to see how this breaks on other platforms when I fix the issue that Benjamin Kramer pointed out. This includes r163489 and r163490, plus a two line change. llvm-svn: 163512
* Revert Ted's r163489 and r163490, due to breakage.NAKAMURA Takumi2012-09-101-135/+11
| | | | | | | r163489, "Take another crack at stabilizing the emission order of analyzer" r163490, "Use isBeforeInTranslationUnitThan() instead of operator<." llvm-svn: 163497
* Use isBeforeInTranslationUnitThan() instead of operator<.Ted Kremenek2012-09-101-7/+7
| | | | llvm-svn: 163490
* Take another crack at stabilizing the emission order of analyzerTed Kremenek2012-09-101-11/+135
| | | | | | | | | | | | | | diagnostics without using FoldingSetNodeIDs. This is done by doing a complete recursive comparison of the PathDiagnostics. Note that the previous method of comparing FoldingSetNodeIDs did not end up relying on unstable things such as pointer addresses, so I suspect this may still have some issues on various buildbots because I'm not sure if the true source of non-determinism has been eliminated. The tests pass for me, so the only way to know is to commit this change and see what happens. llvm-svn: 163489
* Indent the "message" key in analyzer plist output.Ted Kremenek2012-09-101-0/+1
| | | | llvm-svn: 163487
* Remove dead method ProgramState::MarshalState().Ted Kremenek2012-09-091-11/+0
| | | | llvm-svn: 163479
* Fix bug in BugReporter::RemoveUneededCalls() where "prunable"Ted Kremenek2012-09-082-5/+2
| | | | | | | PathDiagnosticEventPieces were *always* pruned. Instead, they are suppose to only be pruned if the entire call gets pruned. llvm-svn: 163460
* Attempt (again) to stabilize the order of the emission of diagnosticsTed Kremenek2012-09-081-31/+17
| | | | | | | of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
* [analyzer] ObjCSelfInitChecker should always clean up in postCall checks.Jordan Rose2012-09-081-4/+4
| | | | | | | | | | | | | | | | | | | | ObjCSelfInitChecker stashes information in the GDM to persist it across function calls; it is stored in pre-call checks and retrieved post-call. The post-call check is supposed to clear out the stored state, but was failing to do so in cases where the call did not have a symbolic return value. This was actually causing the inappropriate cache-out from r163361. Per discussion with Anna, we should never actually cache out when assuming the receiver of an Objective-C message is non-nil, because we guarded that node generation by checking that the state has changed. Therefore, the only states that could reach this exact ExplodedNode are ones that should have merged /before/ making this assumption. r163361 has been reverted and the test case removed, since it won't actually test anything interesting now. llvm-svn: 163449
* Revert "Attempt to make the PathDiagnostic emission order more deterministic by"Ted Kremenek2012-09-081-38/+3
| | | | llvm-svn: 163446
* Revert "Further tweaks to hopefully make the PathDiagnostic emission more ↵Ted Kremenek2012-09-081-8/+18
| | | | | | deterministic." llvm-svn: 163445
* [analyzer] Remove constraints on dead symbols as part of removeDeadBindings.Jordan Rose2012-09-082-9/+8
| | | | | | | | | | | | | Previously, we'd just keep constraints around forever, which means we'd never be able to merge paths that differed only in constraints on dead symbols. Because we now allow constraints on symbolic expressions, not just single symbols, this requires changing SymExpr::symbol_iterator to include intermediate symbol nodes in its traversal, not just the SymbolData leaf nodes. llvm-svn: 163444
* [analyzer] Symbolic regions are live if any subregions are live.Jordan Rose2012-09-081-21/+9
| | | | | | | | | | RegionStoreManager was only treating a SymbolicRegion's symbel as live if there was a binding referring to the region itself. No test case because constraints are currently not being cleaned out of the constraint manager at all (even if the symbol is legitimately dead). llvm-svn: 163443
* [analyzer] Cast the result of a placement new-expression to the correct type.Jordan Rose2012-09-081-1/+3
| | | | | | | | | | | This is necessary because further analysis will assume that the SVal's type matches the AST type. This caused a crash when trying to perform a derived-to-base cast on a C++ object that had been new'd to be another object type. Yet another crash in PR13763. llvm-svn: 163442
* Further tweaks to hopefully make the PathDiagnostic emission more deterministic.Ted Kremenek2012-09-071-18/+8
| | | | llvm-svn: 163430
* Remove ProgramState::getSymVal(). It was being misused by Checkers,Ted Kremenek2012-09-075-8/+56
| | | | | | | | | | | | | | | | | | | | with at least one subtle bug in MacOSXKeyChainAPIChecker where the calling the method was a substitute for assuming a symbolic value was null (which is not the case). We still keep ConstraintManager::getSymVal(), but we use that as an optimization in SValBuilder and ProgramState::getSVal() to constant-fold SVals. This is only if the ConstraintManager can provide us with that information, which is no longer a requirement. As part of this, introduce a default implementation of ConstraintManager::getSymVal() which returns null. For Checkers, introduce ConstraintManager::isNull(), which queries the state to see if the symbolic value is constrained to be a null value. It does this without assuming it has been implicitly constant folded. llvm-svn: 163428
* Attempt to make the PathDiagnostic emission order more deterministic byTed Kremenek2012-09-071-3/+38
| | | | | | looking at PathPieces. llvm-svn: 163427
* Remove ConstraintManager:isEqual(). It is no longer used.Ted Kremenek2012-09-071-6/+0
| | | | llvm-svn: 163425
* [analyzer] Use cast<> instead of getAs<> for a CFGElement known to be a CFGStmt.Jordan Rose2012-09-071-4/+3
| | | | | | | | | | | | When adding the next statement to the CoreEngine's work list, we take care of all the special cases first. We certainly shouldn't be building PostStmts with null statements (the diagnostics machinery assumes such StmtPoints do not exist), and we should find out sooner if we're missing a special case. A refinement of r163402 that should help prevent further issues like PR13760. llvm-svn: 163409
* [analyzer] Don't use the address of a temporary CFGElement.Jordan Rose2012-09-071-1/+2
| | | | | | | | | | | | | | | | | GCC destroys temporary objects more aggressively than clang, so this results in incorrect behavior when compiling GCC Release builds. We could avoid this issue under C++11 by preventing getAs from being called when 'this' is an rvalue: template<class ElemTy> const ElemTy *getAs() const & { ... } template<class ElemTy> const ElemTy *getAs() const && = delete; Unfortunately, we do not have compatibility macros for this behavior yet. This will hopefully fix PR13760 and PR13762. llvm-svn: 163402
* [analyzer] Explain why we need condition 8.Anna Zaks2012-09-071-1/+4
| | | | llvm-svn: 163394
* ExplodedGraph::shouldCollectNode() should not collect nodes for non-Expr StmtsTed Kremenek2012-09-071-3/+3
| | | | | | | | (as this previously was the case before this was refactored). We also shouldn't need to specially handle BinaryOperators since the eagerly-assume heuristic tags such nodes. llvm-svn: 163374
* Fix bug in ConditionBRVisitor where for C++ (and not C) we were not ignoringTed Kremenek2012-09-071-4/+3
| | | | | | | | | | | | | | | | implicit pointer-to-boolean conversions in condition expressions. This would result in inconsistent diagnostic emission between C and C++. A consequence of this is now ConditionBRVisitor and TrackConstraintBRVisitor may emit redundant diagnostics, for example: "Assuming pointer value is null" (TrackConstraintBRVisitor) "Assuming 'p' is null" (ConditionBRVisitor) We need to reconcile the two, and perhaps prefer one over the other in some cases. llvm-svn: 163372
* [analyzer] Fail gracefully when the dynamic type is outside the hierarchy.Jordan Rose2012-09-071-1/+9
| | | | | | | | | | | | | | | | | | | With some particularly evil casts, we can get an object whose dynamic type is not actually a subclass of its static type. In this case, we won't even find the statically-resolved method as a devirtualization candidate. Rather than assert that this situation cannot occur, we now simply check that the dynamic type is not an ancestor or descendent of the static type, and leave it at that. This error actually occurred analyzing LLVM: CallEventManager uses a BumpPtrAllocator to allocate a concrete subclass of CallEvent (FunctionCall), but then casts it to the actual subclass requested (such as ObjCMethodCall) to perform the constructor. Yet another crash in PR13763. llvm-svn: 163367
* [analyzer] Don't crash if we cache out while evaluating an ObjC message.Jordan Rose2012-09-061-2/+3
| | | | | | | | | | | | | | | | A bizarre series of coincidences led us to generate a previously-seen node in the middle of processing an Objective-C message, where we assume the receiver is non-nil. We were assuming that such an assumption would never "cache out" like this, and blithely went on using a null ExplodedNode as the predecessor for the next step in evaluation. Although the test case committed here is complicated, this could in theory happen in other ways as well, so the correct fix is just to test if the non-nil assumption results in an ExplodedNode we've seen before. <rdar://problem/12243648> llvm-svn: 163361
* [analyzer] Don't attempt to devirtualize calls to base class destructors.Jordan Rose2012-09-063-6/+16
| | | | | | | | | | | | | | | | | | | CXXDestructorCall now has a flag for when it is a base destructor call. Other kinds of destructor calls (locals, fields, temporaries, and 'delete') all behave as "whole-object" destructors and do not behave differently from one another (specifically, in these cases we /should/ try to devirtualize a call to a virtual destructor). This was causing crashes in both our internal buildbot, the crash still being tracked in PR13765, and some of the crashes being tracked in PR13763, due to a assertion failure. (The behavior under -Asserts happened to be correct anyway.) Adding this knowledge also allows our DynamicTypePropagation checker to do a bit less work; the special rules about virtual method calls during a destructor only require extra handling during base destructors. llvm-svn: 163348
* Dont cast away const needlessly. Found by gcc48 -Wcast-qual.Roman Divacky2012-09-064-9/+10
| | | | llvm-svn: 163325
* [analyzer] Enhance the member expr tracking to account for references.Anna Zaks2012-09-051-1/+8
| | | | | | As per Jordan's suggestion. (Came out of code review for r163261.) llvm-svn: 163269
* [analyzer] Always include destructors in the analysis CFG.Jordan Rose2012-09-052-2/+7
| | | | | | | | | | | | | | | | | | | | | While destructors will continue to not be inlined (unless the analyzer config option 'c++-inlining' is set to 'destructors'), leaving them out of the CFG is an incomplete model of the behavior of an object, and can cause false positive warnings (like PR13751, now working). Destructors for temporaries are still not on by default, since (a) we haven't actually checked this code to be sure it's fully correct (in particular, we probably need to be very careful with regard to lifetime-extension when a temporary is bound to a reference, C++11 [class.temporary]p5), and (b) ExprEngine doesn't actually do anything when it sees a temporary destructor in the CFG -- not even invalidate the object region. To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which controlled all implicit destructors, has been removed. llvm-svn: 163264
* [analyzer] Fix a crash PR13762.Anna Zaks2012-09-051-1/+2
| | | | llvm-svn: 163262
* [analyzer] NullOrUndef diagnostics: track symbols binded to regions.Anna Zaks2012-09-051-8/+12
| | | | | | | | | If a region is binded to a symbolic value, we should track the symbol. (The code I changed was not previously exercised by the regression tests.) llvm-svn: 163261
* [analyzer] Be more forgiving about calling methods on struct rvalues.Jordan Rose2012-09-052-3/+23
| | | | | | | | | | | | | | | | | | | | The problem is that the value of 'this' in a C++ member function call should always be a region (or NULL). However, if the object is an rvalue, it has no associated region (only a conjured symbol or LazyCompoundVal). For now, we handle this in two ways: 1) Actually respect MaterializeTemporaryExpr. Before, it was relying on CXXConstructExpr to create temporary regions for all struct values. Now it just does the right thing: if the value is not in a temporary region, create one. 2) Have CallEvent recognize the case where its 'this' pointer is a non-region, and just return UnknownVal to keep from confusing clients. The long-term problem is being tracked internally in <rdar://problem/12137950>, but this makes many test cases pass. llvm-svn: 163220
* [analyzer] Clean up a couple uses of getPointeeType().Jordan Rose2012-09-053-15/+7
| | | | | | No intended functionality change. llvm-svn: 163219
* Revert "[analyzer] Treat all struct values as regions (even rvalues)."Jordan Rose2012-09-052-20/+3
| | | | | | | | | | | | | | This turned out to have many implications, but what eventually seemed to make it unworkable was the fact that we can get struct values (as LazyCompoundVals) from other places besides return-by-value function calls; that is, we weren't actually able to "treat all struct values as regions" consistently across the entire analyzer core. Hopefully we'll be able to come up with an alternate solution soon. This reverts r163066 / 02df4f0aef142f00d4637cd851e54da2a123ca8e. llvm-svn: 163218
* [analyzer] Don't use makeIntVal to create a floating-point value.Jordan Rose2012-09-041-1/+3
| | | | | | | | | | SimpleSValBuilder processes a couple trivial identities, including 'x - x' and 'x ^ x' (both 0). However, the former could appear with arguments of floating-point type, and we weren't checking for that. This started triggering an assert with r163069, which checks that a constant value is actually going to be used as an integer or pointer. llvm-svn: 163159
* Revert r163083 per chandlerc's request.Joao Matos2012-09-041-1/+0
| | | | llvm-svn: 163149
* Implemented parsing and AST support for the MS __leave exception statement. ↵Joao Matos2012-09-021-0/+1
| | | | | | Also a minor fix to __except printing in StmtPrinter.cpp. Thanks to Aaron Ballman for review. llvm-svn: 163083
* [analyzer] Silence unused variable warnings in NDEBUG builds.Jordan Rose2012-09-011-0/+2
| | | | | | No functionality change. llvm-svn: 163073
* [analyzer] Disallow creation of int vals with explicit bit width / signedness.Jordan Rose2012-09-011-5/+1
| | | | | | | | | | All clients of BasicValueFactory should be using QualTypes instead, and indeed it seems they are. This caught the (fortunately harmless) bug fixed in the previous commit. No intended functionality change. llvm-svn: 163069
* [analyzer] Don't attempt to create a floating-point value of "1" for ++/--.Jordan Rose2012-09-011-1/+3
| | | | | | | | | | | The current logic would actually create a float- or double-sized signed integer value of 1, which is not at all the same. No test because the value would be swallowed by an Unknown as soon as it gets added or subtracted to the original value, but it enables the cleanup in the next patch. llvm-svn: 163068
* [analyzer] Treat all struct values as regions (even rvalues).Jordan Rose2012-09-012-3/+20
| | | | | | | | | | | | | | | | | This allows us to correctly symbolicate the fields of structs returned by value, as well as get the proper 'this' value for when methods are called on structs returned by value. This does require a moderately ugly hack in the StoreManager: if we assign a "struct value" to a struct region, that now appears as a Loc value being bound to a region of struct type. We handle this by simply "dereferencing" the struct value region, which should create a LazyCompoundVal. This should fix recent crashes analyzing LLVM and on our internal buildbot. <rdar://problem/12137950> llvm-svn: 163066
* [analyzer] Always derive a CallEvent's return type from its origin expr.Jordan Rose2012-09-011-28/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we preferred to get a result type by looking at the callee's declared result type. This allowed us to handlereferences, which are represented in the AST as lvalues of their pointee type. (That is, a call to a function returning 'int &' has type 'int' and value kind 'lvalue'.) However, this results in us preferring the original type of a function over a casted type. This is a problem when a function pointer is casted to another type, because the conjured result value will have the wrong type. AdjustedReturnValueChecker is supposed to handle this, but still doesn't handle the case where there is no "original function" at all, i.e. where the callee is unknown. Now, we instead look at the call expression's value kind (lvalue, xvalue, or prvalue), and adjust the expr's type accordingly. This will have no effect when the function is inlined, and will conjure the value that will actually be used when it is not. This makes AdjustedReturnValueChecker /nearly/ unnecessary; unfortunately, the cases where it would still be useful are where we need to cast the result of an inlined function or a checker-evaluated function, and in these cases we don't know what we're casting /from/ by the time we can do post- call checks. In light of that, remove AdjustedReturnValueChecker, which was already not checking quite a few calls. llvm-svn: 163065
* Split library clangRewrite into clangRewriteCore and clangRewriteFrontend.Ted Kremenek2012-09-012-3/+3
| | | | | | | This is similar to how we divide up the StaticAnalyzer libraries to separate core functionality to what is clearly associated with Frontend actions. llvm-svn: 163050
* [analyzer] Though C++ inlining is enabled, don't inline ctors and dtors.Jordan Rose2012-08-313-30/+63
| | | | | | | | | | | | | | | | More generally, this adds a new configuration option 'c++-inlining', which controls which C++ member functions can be considered for inlining. This uses the new -analyzer-config table, so the cc1 arguments will look like this: ... -analyzer-config c++-inlining=[none|methods|constructors|destructors] Note that each mode implies that all the previous member function kinds will be inlined as well; it doesn't make sense to inline destructors without inlining constructors, for example. The default mode is 'methods'. llvm-svn: 163004
* [analyzer] Ensure that PathDiagnostics profile the same regardless of path.Jordan Rose2012-08-315-48/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | PathDiagnostics are actually profiled and uniqued independently of the path on which the bug occurred. This is used to merge diagnostics that refer to the same issue along different paths, as well as by the plist diagnostics to reference files created by the HTML diagnostics. However, there are two problems with the current implementation: 1) The bug description is included in the profile, but some PathDiagnosticConsumers prefer abbreviated descriptions and some prefer verbose descriptions. Fixed by including both descriptions in the PathDiagnostic objects and always using the verbose one in the profile. 2) The "minimal" path generation scheme provides extra information about which events came from macros that the "extensive" scheme does not. This resulted not only in different locations for the plist and HTML diagnostics, but also in diagnostics being uniqued in the plist output but not in the HTML output. Fixed by storing the "end path" location explicitly in the PathDiagnostic object, rather than trying to find the last piece of the path when the diagnostic is requested. This should hopefully finish unsticking our internal buildbot. llvm-svn: 162965
OpenPOWER on IntegriCloud