| Age | Commit message (Collapse) | Author |
|---|
|
After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.
The next commit relies on this behavior to actually test anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrapped in a
MaterializeTemporaryExpr, which lets CodeGen know to create a temporary
region to store this value. However, MaterializeTemporaryExprs are /not/
created when a method is called on an rvalue struct, even though the 'this'
pointer needs a valid value. CodeGen works around this by creating a
temporary region anyway; now, so does the analyzer.
The analyzer also does this when accessing a field of a struct rvalue.
This is a little unfortunate, since the rest of the struct will soon be
thrown away, but it does make things consistent with the rest of the
analyzer.
This allows us to bring back the assumption that all known 'this' values
are Locs. This is a revised version of r164828-9, reverted in r164876-7.
<rdar://problem/12137950>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166120 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
an lvalue."
The original intent of this commit was to catch potential null dereferences
early, but it breaks the common "home-grown offsetof" idiom (PR13927):
(((struct Foo *)0)->member - ((struct foo *)0))
As it turns out, this appears to be legal in C, per a footnote in
C11 6.5.3.2: "Thus, &*E is equivalent to E (even if E is a null pointer)".
In C++ this issue is still open:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
We'll just have to make sure we have good path notes in the future.
This reverts r164441 / 9be016dcd1ca3986873a7b66bd4bc027309ceb59.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is possible and valid to have a state manager and associated objects
without having a SubEngine or checkers.
Patch by Olaf Krzikalla!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164947 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accessing fields"
This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rvalue."
This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164876 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
An rvalue has no address, but calling a C++ member function requires a
'this' pointer. This commit makes the analyzer create a temporary region
in which to store the struct rvalue and use as a 'this' pointer whenever
a member function is called on an rvalue, which is essentially what
CodeGen does.
More of <rdar://problem/12137950>. The last part is tracking down the
C++ FIXME in array-struct-region.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164829 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Struct rvalues are represented in the analyzer by CompoundVals,
LazyCompoundVals, or plain ConjuredSymbols -- none of which have associated
regions. If the entire structure is going to persist, this is not a
problem -- either the rvalue will be assigned to an existing region, or
a MaterializeTemporaryExpr will be present to create a temporary region.
However, if we just need a field from the struct, we need to create the
temporary region ourselves.
This is inspired by the way CodeGen handles calls to temporaries;
support for that in the analyzer is coming next.
Part of <rdar://problem/12137950>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164828 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We want to catch cases like this early, so that we can produce better
diagnostics and path notes:
Point *p = 0;
int *px = &p->x; // should warn here
*px = 1;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in NSException to a helper object in libAnalysis that can also
be used by Sema. Not sure if the predicate name 'isImplicitNoReturn'
is the best one, but we can massage that later.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameter packs where the reference is not being expanded but the pack has
been. Previously, Clang would segfault in such cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163325 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
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
|
|
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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
individual flags.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162929 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
This allows us to better reason about status objects, like Clang's own
llvm::Optional (when its contents are trivially destructible), which are
often intended to be passed around by value.
We still don't inline constructors for temporaries in the general case.
<rdar://problem/11986434>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows checkers (like the MallocChecker) to process the effects of the
bind. Previously, using a memory-allocating function (like strdup()) in an
initializer would result in a leak warning.
This does bend the expectations of checkBind a bit; since there is no
assignment expression, the statement being used is the initializer value.
In most cases this shouldn't matter because we'll use a PostInitializer
program point (rather than PostStmt) for any checker-generated nodes, though
we /will/ generate a PostStore node referencing the internal statement.
(In theory this could have funny effects if someone actually does an
assignment within an initializer; in practice, that seems like it would be
very rare.)
<rdar://problem/12171711>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162637 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Until we have full support for pointers-to-members, we can at least
approximate some of their use by tracking null and non-null values.
We thus treat &A::m_ptr as a non-null void * symbol, and MemberPointer(0)
as a pointer-sized null constant.
This enables support for what is sometimes called the "safe bool" idiom,
demonstrated in the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162495 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A CXXDefaultArgExpr wraps an Expr owned by a ParmVarDecl belonging to the
called function. In general, ExprEngine and Environment ought to treat this
like a ParenExpr or other transparent wrapper expression, with the inside
expression evaluated first.
However, if we call the same function twice, we'd produce a CFG that contains
the same wrapped expression twice, and we're not set up to handle that. I've
added a FIXME to the CFG builder to come back to that, but meanwhile we can
at least handle expressions that don't need to be explicitly evaluated:
literals. This probably handles many common uses of default parameters:
true/false, null, etc.
Part of PR13385 / <rdar://problem/12156507>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also rename 'getCurrentBlockCounter()' to 'blockCount()'.
This ripples a bunch of code simplifications; mostly aesthetic,
but makes the code a bit tighter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No need to have the "get", the word "conjure" is a verb too!
Getting a conjured symbol is the same as conjuring one up.
This shortening is largely cosmetic, but just this simple changed
cleaned up a handful of lines, making them less verbose.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
all forwarding methods.
This functionality is already covered by bindLoc().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Generating a sink is significantly different behavior from generating a
normal node, and a simple boolean parameter can be rather opaque. Per
offline discussion with Anna, adding new generation methods is the
clearest way to communicate intent.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162215 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Our current handling of 'throw' is all CFG-based: it jumps to a 'catch' block
if there is one and the function exit block if not. But this doesn't really
get the right behavior when a function is inlined: execution will continue on
the caller's side, which is always the wrong thing to do.
Even within a single function, 'throw' completely skips any destructors that
are to be run. This is essentially the same problem as @finally -- a CFGBlock
that can have multiple entry points, whose exit points depend on whether it
was entered normally or exceptionally.
Representing 'throw' as a sink matches our current (non-)handling of @throw.
It's not a perfect solution, but it's better than continuing analysis in an
inconsistent or even impossible state.
<rdar://problem/12113713>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162157 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The CFG approximates @throw as a return statement, but that's not good
enough in inlined functions. Moreover, since Objective-C exceptions are
usually considered fatal, we should be suppressing leak warnings like we
do for calls to noreturn functions (like abort()).
The comments indicate that we were probably intending to do this all along;
it may have been inadvertantly changed during a refactor at one point.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162156 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Like base constructors, delegating constructors require no further
processing in the CFGInitializer node.
Also, add PrettyStackTraceLoc to the initializer and destructor logic
so we can get better stack traces in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was causing a crash in our array-to-pointer logic, since the region
was clearly not an array.
PR13440 / <rdar://problem/11977113>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161051 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This ensures that it is valid to reference-count any CallEvents, and we
won't accidentally try to reclaim a CallEvent that lives on the stack.
It also hides an ugly switch statement for handling CallExprs!
There should be no functionality change here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We were treating this like a CXXDefaultArgExpr, but
SubstNonTypeTemplateParmExpr actually appears when a template is
instantiated, i.e. we have all the information necessary to evaluate it.
This allows us to inline functions like llvm::array_lengthof.
<rdar://problem/11949235>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160846 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Passing a temporary via reference parameter still requires a visible
copy constructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This uses CFG to tell if a constructor call is for a member, and uses
the member's region appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.
This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As pointed out by Anna, we only differentiate between explicit message sends
This also adds support for ObjCSubscriptExprs, which are basically the same
as properties in many ways. We were already checking these, but not emitting
nice messages for them.
This depends on the llvm::PointerIntPair change in r160456.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ObjC properties are handled through their semantic form of ObjCMessageExprs
and their wrapper PseudoObjectExprs, and have been for quite a while. The
syntactic ObjCPropertyRefExprs do not appear in the CFG and are not visited
by ExprEngine.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
used in a branch, but
instead push the terminator for the branch down into the basic blocks of the subexpressions of '&&' and '||'
respectively. This eliminates some artifical control-flow from the CFG and results in a more
compact CFG.
Note that this patch only alters the branches 'while', 'if' and 'for'. This was complex enough for
one patch. The remaining branches (e.g., do...while) can be handled in a separate patch, but they
weren't immediately tackled because they were less important.
It is possible that this patch introduces some subtle bugs, particularly w.r.t. to destructor placement.
I've tried to audit these changes, but it is also known that the destructor logic needs some refinement
in the area of '||' and '&&' regardless (i.e., their are known bugs).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160218 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also contains a number of tweaks to inlining that are necessary
for constructors and destructors. (I have this enabled on a private
branch, but it is very much unstable.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160023 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These ProgramPoints are used in inlining calls,
and not all calls have associated statements anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These are currently unused, but are intended to be used in lieu of PreStmt
and PostStmt when the call is implicit (e.g. an automatic object destructor).
This also modifies the Data1 field of ProgramPoints to allow storing any
pointer-sized value, as opposed to only aligned pointers. This is necessary
to store SourceLocations.
There is currently no BugReporter support for these; they should be skipped
over in any diagnostic output.
This commit also tags checkers that currently rely on function calls only
occurring at StmtPoints.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160019 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
code."
...and instead add an accessor. We're not using this today, but it's something
that should probably stay in the source for potential clients, and it doesn't
cost a lot. (ObjCPropertyAccess is only created on the stack, and right now
there's only ever one alive at a time.)
This reverts r159581 / commit 8e674e1da34a131faa7d43dc3fcbd6e49120edbe.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159595 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This member became unused in r159559.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159581 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The preObjCMessage and postObjCMessage callbacks now take an ObjCMethodCall
argument, which can represent an explicit message send (ObjCMessageSend) or an
implicit message generated by a property access (ObjCPropertyAccess).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159559 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, the CallEvent subclass ObjCMessageInvocation was just a wrapper
around the existing ObjCMessage abstraction (over message sends and property
accesses). Now, we have abstract CallEvent ObjCMethodCall with subclasses
ObjCMessageSend and ObjCPropertyAccess.
In addition to removing yet another wrapper object, this should make it easy
to add a ObjCSubscriptAccess call event soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159558 91177308-0d34-0410-b5e6-96231b3b80d8
|
