| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
For now this will stay on, but this way it's easy to switch off if we need
to pull back our support for a while.
llvm-svn: 161064
|
|
|
|
| |
llvm-svn: 161060
|
|
|
|
|
|
|
|
| |
While usually we'd use a symbolic region rather than a straight-up Unknown,
we can still generate unknowns via array subscripts with symbolic indexes.
(And if this ever changes in the future, we still shouldn't crash.)
llvm-svn: 161059
|
|
|
|
| |
llvm-svn: 161058
|
|
|
|
|
|
|
|
|
| |
This was causing a crash in our array-to-pointer logic, since the region
was clearly not an array.
PR13440 / <rdar://problem/11977113>
llvm-svn: 161051
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes explicit checks for 'this' and 'self' from
Store::enterStackFrame. It also removes getCXXThisRegion() as a virtual
method on all CallEvents; it's now only implemented in the parts of the
hierarchy where it is relevant. Finally, it removes the option to ask
for the ParmVarDecls attached to the definition of an inlined function,
saving a recomputation of the result of getRuntimeDefinition().
No visible functionality change!
llvm-svn: 161017
|
|
|
|
|
|
|
| |
Use self-init.m for testing. (It used to have a bunch of failing tests
with dynamic inlining turned on.)
llvm-svn: 161012
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were only checking the origin expressions of inlined calls.
Checkers using the generic postCall and older postObjCMessage callbacks were
ignored. Now that we have CallEventManager, it is much easier to create
a CallEvent generically when exiting an inlined function, which we can then
use for post-call checks.
No test case because we don't (yet) have any checkers that depend on this
behavior (which is why it hadn't been fixed before now).
llvm-svn: 161005
|
|
|
|
|
|
|
|
|
| |
- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).
llvm-svn: 160991
|
|
|
|
|
|
|
|
| |
dispatched methods.
Disabled by default for now.
llvm-svn: 160988
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 160986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to get around the C++ "virtual constructor" problem
when we'd like to create a CallEvent from an ExplodedNode, an inlined
StackFrameContext, or another CallEvent. The solution has three parts:
- CallEventManager uses a BumpPtrAllocator to allocate CallEvent-sized
memory blocks. It also keeps a cache of freed CallEvents for reuse.
- CallEvents all have protected copy constructors, along with cloneTo()
methods that use placement new to copy into CallEventManager-managed
memory, vtables intact.
- CallEvents owned by CallEventManager are now wrapped in an
IntrusiveRefCntPtr. Going forwards, it's probably a good idea to create
ALL CallEvents through the CallEventManager, so that we don't accidentally
try to reclaim a stack-allocated CallEvent.
All of this machinery is currently unused but will be put into use shortly.
llvm-svn: 160983
|
|
|
|
| |
llvm-svn: 160851
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 160846
|
|
|
|
|
|
|
|
| |
It's a good thing CallEvents aren't created all over the place yet.
I checked all the uses this time and the private copy constructor
/really/ shouldn't cause any more problems.
llvm-svn: 160845
|
|
|
|
|
|
|
| |
Passing a temporary via reference parameter still requires a visible
copy constructor.
llvm-svn: 160840
|
|
|
|
|
|
|
|
|
|
|
| |
ExprEngine::VisitGuardedExpr
instead of walking to the preceding PostStmt node. There are cases where the last evaluated
expression does not appear in the ExplodedGraph.
Fixes PR 13466.
llvm-svn: 160819
|
|
|
|
|
|
|
|
| |
After discussion, the type-based dispatch was decided to be bad for
maintenance and made it very easy for subtle bugs to creep in. Instead,
we'll just be very careful when we do have to allocate these on the heap.
llvm-svn: 160817
|
|
|
|
| |
llvm-svn: 160815
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our BugReporter knows how to deal with implicit statements: it looks in
the ParentMap until it finds a parent with a valid location. However, since
initializers are not in the body of a constructor, their sub-expressions are
not in the ParentMap. That was easy enough to fix in AnalysisDeclContext.
...and then even once THAT was fixed, there's still an extra funny case
of Objective-C object pointer fields under ARC, which are initialized with
a top-level ImplicitValueInitExpr. To catch these cases,
PathDiagnosticLocation will now fall back to the start of the current
function if it can't find any other valid SourceLocations. This isn't great,
but it's miles better than a crash.
(All of this is only relevant when constructors and destructors are being
inlined, i.e. under -cfg-add-initializers and -cfg-add-implicit-dtors.)
llvm-svn: 160810
|
|
|
|
|
|
|
|
| |
This workaround is fairly lame: we simulate the first element's constructor
and destructor and rely on the region invalidation to "initialize" the rest
of the elements.
llvm-svn: 160809
|
|
|
|
|
|
|
| |
This uses CFG to tell if a constructor call is for a member, and uses
the member's region appropriately.
llvm-svn: 160808
|
|
|
|
|
|
|
|
|
| |
Previously we were using ParentMap and crawling through the parent DeclStmt.
This should be at least slightly cheaper (and is also more flexible).
No (intended) functionality change.
llvm-svn: 160807
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 160806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
llvm-svn: 160804
|
|
|
|
|
|
|
| |
At the very least this means initializer nodes for constructors and
automatic object destructors are present in the CFG.
llvm-svn: 160803
|
|
|
|
|
|
|
| |
This avoids an assertion crash when we invalidate on a destructor call
instead of inlining it.
llvm-svn: 160802
|
|
|
|
|
|
|
|
|
|
| |
- Some cleanup(the TODOs) will be done after ObjC method inlining is
complete.
- Simplified CallEvent::getDefinition not to require ISDynamicDispatch
parameter.
- Also addressed Jordan's comments from r160530.
llvm-svn: 160768
|
|
|
|
|
|
| |
needed).
llvm-svn: 160764
|
|
|
|
| |
llvm-svn: 160761
|
|
|
|
|
|
|
|
| |
value by scanning the path, rather than assuming we have visited the '?:' operator
as a terminator (which sets a value indicating which expression to grab the
final ternary expression value from).
llvm-svn: 160760
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
| |
clang's -Wunused-private-field.
llvm-svn: 160584
|
|
|
|
|
|
| |
same implementation for call evaluation.
llvm-svn: 160530
|
|
|
|
| |
llvm-svn: 160488
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 160461
|
|
|
|
|
|
|
|
|
| |
Per Anna's comment that "add..." sounds like a method that modifies
the receiver, rather than its argument.
No functionality change.
llvm-svn: 160460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We will need to be able to easily reconstruct a CallEvent from an ExplodedNode
for diagnostic purposes, and that's exactly what factory functions are for.
CallEvent objects are small enough (four pointers and a SourceLocation) that
returning them through the stack is fairly cheap. Clients who just need to use
existing CallEvents can continue to do so using const references.
This uses the same sort of "kind-field-dispatch" as SVal, though most of the
nastiness is contained in the DISPATCH and DISPATCH_ARG macros at the end of
the file. (We can't use a template for this because member-pointers to base
class methods don't call derived-class methods even when casting to the
derived class. We can't use variadic macros because they're a C99 feature.)
llvm-svn: 160459
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 160458
|
|
|
|
| |
llvm-svn: 160457
|
|
|
|
|
|
|
|
|
|
| |
references
(in uses of dynamic_cast<>).
Fixes <rdar://problem/11817693>.
llvm-svn: 160427
|
|
|
|
|
|
|
| |
This code has been moved around multiple times, but seems to have been
obsolete ever since we started handled references like pointers.
llvm-svn: 160375
|
|
|
|
|
|
| |
<rdar://problem/11818967>
llvm-svn: 160328
|
|
|
|
| |
llvm-svn: 160257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 160218
|
|
|
|
|
|
|
|
| |
Previously we were using the static type of the base object to inline
methods, whether virtual or non-virtual. Now, we try to see if the base
object has a known type, and if so ask for its implementation of the method.
llvm-svn: 160094
|
|
|
|
|
|
|
|
|
|
| |
This is probably not so useful yet because it is not path-sensitive, though
it does try to show inlining with indentation.
This also adds a dump() method to CallEvent, which should be useful for
debugging.
llvm-svn: 160030
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 160023
|
|
|
|
|
|
|
|
|
|
| |
In order to accomplish this, we now build the callee's stack frame
as part of the CallEnter node, rather than the subsequent BlockEdge node.
This should not have any effect on perceived behavior or diagnostics.
This makes it safe to re-enable inlining of member overloaded operators.
llvm-svn: 160022
|
|
|
|
|
|
|
| |
These ProgramPoints are used in inlining calls,
and not all calls have associated statements anymore.
llvm-svn: 160021
|