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

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

llvm-svn: 160767

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

to fix all the issues.  Currently the code is essentially unmaintained and buggy, and
needs major revision (with coupled enhancements to the analyzer core).

llvm-svn: 160754

llvm-svn: 160706

llvm-svn: 160622

Remove unused private member variable uncovered by the recent changes to 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

This enables the faster SmallVector in clang and also allows clang's unused
variable warnings to be more effective. Fix the two instances that popped up.

The RetainCountChecker change actually changes functionality, it would be nice
if someone from the StaticAnalyzer folks could look at it.

llvm-svn: 160444

(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