Un-break standalone invocations of CmpRuns.py.

Fallout from CmpRuns.py API changes in r160314.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160800 91177308-0d34-0410-b5e6-96231b3b80d8
Add a const version of Expr::IgnoreImplicit. No functionality change.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160801 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] PostImplicitCall can also occur between CFGElements.

This avoids an assertion crash when we invalidate on a destructor call
instead of inlining it.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160802 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Inline ctors + dtors when the CFG is built for them.

At the very least this means initializer nodes for constructors and
automatic object destructors are present in the CFG.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160803 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Show paths for destructor calls.

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.)

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160804 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Variables with destructors are live until the destructor is run.

Test case in the next commit, which enables destructors under certain
circumstances.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160805 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Handle base class initializers and destructors.

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: http://llvm.org/svn/llvm-project/cfe/trunk@160806 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Use the CFG to see if a constructor is for a local variable.

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.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160807 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Handle C++ member initializers and destructors.

This uses CFG to tell if a constructor call is for a member, and uses
the member's region appropriately.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160808 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Don't crash on array constructors and destructors.

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.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160809 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Don't crash on implicit statements inside initializers.

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.)

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@160810 91177308-0d34-0410-b5e6-96231b3b80d8