aboutsummaryrefslogtreecommitdiff
path: root/lib/StaticAnalyzer/Core
AgeCommit message (Collapse)Author
2012-09-08[analyzer] Cast the result of a placement new-expression to the correct type.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163442 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07Further tweaks to hopefully make the PathDiagnostic emission more deterministic.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163430 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07Remove ProgramState::getSymVal(). It was being misused by Checkers,Ted Kremenek
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163428 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07Attempt to make the PathDiagnostic emission order more deterministic byTed Kremenek
looking at PathPieces. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163427 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07Remove ConstraintManager:isEqual(). It is no longer used.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163425 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07[analyzer] Use cast<> instead of getAs<> for a CFGElement known to be a CFGStmt.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163409 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07[analyzer] Don't use the address of a temporary CFGElement.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163402 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07[analyzer] Explain why we need condition 8.Anna Zaks
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163394 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07ExplodedGraph::shouldCollectNode() should not collect nodes for non-Expr StmtsTed Kremenek
(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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163374 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07Fix bug in ConditionBRVisitor where for C++ (and not C) we were not ignoringTed Kremenek
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163372 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-07[analyzer] Fail gracefully when the dynamic type is outside the hierarchy.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163367 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-06[analyzer] Don't crash if we cache out while evaluating an ObjC message.Jordan Rose
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> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163361 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-06[analyzer] Don't attempt to devirtualize calls to base class destructors.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163348 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-06Dont cast away const needlessly. Found by gcc48 -Wcast-qual.Roman Divacky
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163325 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] Enhance the member expr tracking to account for references.Anna Zaks
As per Jordan's suggestion. (Came out of code review for r163261.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163269 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] Always include destructors in the analysis CFG.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163264 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] Fix a crash PR13762.Anna Zaks
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163262 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] NullOrUndef diagnostics: track symbols binded to regions.Anna Zaks
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.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163261 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] Be more forgiving about calling methods on struct rvalues.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163220 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05[analyzer] Clean up a couple uses of getPointeeType().Jordan Rose
No intended functionality change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163219 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-05Revert "[analyzer] Treat all struct values as regions (even rvalues)."Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163218 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-04[analyzer] Don't use makeIntVal to create a floating-point value.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163159 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-04Revert r163083 per chandlerc's request.Joao Matos
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163149 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-02Implemented parsing and AST support for the MS __leave exception statement. ↵Joao Matos
Also a minor fix to __except printing in StmtPrinter.cpp. Thanks to Aaron Ballman for review. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163083 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01[analyzer] Silence unused variable warnings in NDEBUG builds.Jordan Rose
No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163073 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01[analyzer] Disallow creation of int vals with explicit bit width / signedness.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163069 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01[analyzer] Don't attempt to create a floating-point value of "1" for ++/--.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163068 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01[analyzer] Treat all struct values as regions (even rvalues).Jordan Rose
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> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163066 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01[analyzer] Always derive a CallEvent's return type from its origin expr.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163065 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-01Split library clangRewrite into clangRewriteCore and clangRewriteFrontend.Ted Kremenek
This is similar to how we divide up the StaticAnalyzer libraries to separate core functionality to what is clearly associated with Frontend actions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163050 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-31[analyzer] Though C++ inlining is enabled, don't inline ctors and dtors.Jordan Rose
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'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163004 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-31[analyzer] Ensure that PathDiagnostics profile the same regardless of path.Jordan Rose
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162965 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-31[analyzer] Fix a crash in plist-html generation introduced in r162939.Jordan Rose
Basically, do the correct thing to fix the XML generation error, rather than making it even worse by unilaterally dereferencing a null pointer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162964 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-31Change the representation of builtin functions in the ASTEli Friedman
(__builtin_* etc.) so that it isn't possible to take their address. Specifically, introduce a new type to represent a reference to a builtin function, and a new cast kind to convert it to a function pointer in the operand of a call. Fixes PR13195. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162962 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-30[analyzer] Refactor the logic that determines if a functions should beAnna Zaks
reanalyzed. The policy on what to reanalyze should be in AnalysisConsumer with the rest of visitation order logic. There is no reason why ExprEngine needs to pass the Visited set to CoreEngine, it can populate it itself. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162957 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-30[analyzer] Plist diagnostics: Fix a case where we fail to close an XML tag.Jordan Rose
If the current path diagnostic does /not/ have files associated with it, we were simply skipping on to the next diagnostic with 'continue'. But that also skipped the close tag for the diagnostic's <dict> node. Part of fixing our internal analyzer buildbot. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162939 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-30Rename 'MaxLoop' to 'maxBlockVisitOnPath' to reflect reality. WeTed Kremenek
should consider renaming the command line option as well. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162932 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-30Rename AnalyzerOptions 'EagerlyAssume' to 'eagerlyAssumeBinOpBifurcation'.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162930 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-30Store const& to AnalyzerOptions in AnalysisManager instead of copyingTed Kremenek
individual flags. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162929 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-29[analyzer] Fixup 162863.Anna Zaks
Thanks Jordan. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162875 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-29[analyzer] Improved diagnostic pruning for calls initializing values.Anna Zaks
This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162863 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-29Add new -cc1 driver option -analyzer-config, which allows one to specifyTed Kremenek
a comma separated collection of key:value pairs (which are strings). This allows a general way to provide analyzer configuration data from the command line. No clients yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162827 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] Teach CallEventManager that CXXTemporaryObjectExpr is also a ctor.Jordan Rose
Specifically, CallEventManager::getCaller was looking at the call site for an inlined call and trying to see what kind of call it was, but it only checked for CXXConstructExprClass. (It's not using an isa<> here to avoid doing three more checks on the the statement class.) This caused an unreachable when we actually did inline the constructor of a temporary object. PR13717 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162792 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] When we look for the last stmt in a function, skip implicit dtors.Jordan Rose
When exiting a function, the analyzer looks for the last statement in the function to see if it's a return statement (and thus bind the return value). However, the search for "the last statement" was accepting statements that were in implicitly-generated inlined functions (i.e. destructors). So we'd go and get the statement from the destructor, and then say "oh look, this function had no explicit return...guess there's no return value". And /that/ led to the value being returned being declared dead, and all our leak checkers complaining. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162791 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] Don't purge dead symbols at the end of calls if -analyzer-purge=none.Jordan Rose
No test case since this is a debug option that we will never turn on by default since it makes the leak checkers much less useful. (We'll only report leaks at the end of analysis if -analyzer-purge=none.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162772 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] Rename addTrackNullOrUndefValueVisitor to trackNullOrUndefValue.Jordan Rose
This helper function (in the clang::ento::bugreporter namespace) may add more than one visitor, but conceptually it's tracking a single use of a null or undefined value and should do so as best it can. Also, the BugReport parameter has been made a reference to underscore that it is non-optional. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162720 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] Refactor FindLastStoreBRVisitor to not find the store ahead of time.Jordan Rose
As Anna pointed out to me offline, it's a little silly to walk backwards through the graph to find the store site when BugReporter will do the exact same walk as part of path diagnostic generation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162719 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] If the last store into a region came from a function, step into it.Jordan Rose
Previously, if we were tracking stores to a variable 'x', and came across this: x = foo(); ...we would simply emit a note here and stop. Now, we'll step into 'foo' and continue tracking the returned value from there. <rdar://problem/12114689> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162718 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-28[analyzer] Rename CallEvent::mayBeInlined to CallEvent::isCallStmt.Jordan Rose
The two callers are using this in order to be conservative, so let's just clarify the information that's actually being provided here. This is not related to inlining decisions in any way. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162717 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-27[analyzer] Look through casts when trying to track a null pointer dereference.Jordan Rose
Also, add comments to addTrackNullOrUndefValueVisitor. Thanks for the review, Anna! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162695 91177308-0d34-0410-b5e6-96231b3b80d8