We now check the type of the super-region pointer for most SubRegion classes
in compile time; some checks are run-time though.

This is an API-breaking change (we now require explicit casts to specific region
sub-classes), but in practice very few checkers are affected.

Differential Revision: https://reviews.llvm.org/D26838


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

This patch adds LocationContext to checkRegionChanges and removes
wantsRegionChangeUpdate as it was unused.

A patch by Krzysztof Wiśniewski!

Differential Revision: https://reviews.llvm.org/D27090

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

The analyzer's CFG currently doesn't have nodes for calls to temporary
destructors. This causes the analyzer to explore infeasible paths in which
a no-return destructor would have stopped exploration and so results in false
positives when no-return destructors are used to implement assertions.

To mitigate these false positives, this patch stops generates a sink after
evaluating a constructor on a temporary object that has a no-return destructor.
This results in a loss of coverage because the time at which the destructor is
called may be after the time of construction (especially for lifetime-extended
temporaries).

This addresses PR15599.

rdar://problem/29131566

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

Reading from a garbage pointer should be modeled as garbage,
and performTrivialCopy should be able to deal with any SVal input.

Patch by Ilya Palachev!

Differential Revision: https://reviews.llvm.org/D25727


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

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

When the analyzer evaluates a CXXConstructExpr, it looks ahead in the CFG for
the current block to detect what region the object should be constructed into.
If the constructor was directly constructed into a local variable or field
region then there is no need to explicitly bind the constructed value to
the local or field when analyzing the DeclStmt or CXXCtorInitializer that
called the constructor.

Unfortunately, there were situations in which the CXXConstructExpr was
constructed into a temporary region but when evaluating the corresponding
DeclStmt or CXXCtorInitializer the analyzer assumed the object was constructed
into the local or field. This led to spurious warnings about uninitialized
values (PR25777).

To avoid these false positives, this commit factors out the logic for
determining when a CXXConstructExpr will be directly constructed into existing
storage, adds the inverse logic to detect when the corresponding later bind can
be safely skipped, and adds assertions to make sure these two checks are in
sync.

rdar://problem/21947725

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

When a C++ lambda captures a variable-length array, it creates a capture
field to store the size of the array. The initialization expression for this
capture is null, which led the analyzer to crash when initializing the field.
To avoid this, use the size expression from the VLA type to determine the
initialization value.

rdar://problem/23748072

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

Differential Revision: http://reviews.llvm.org/D12652



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

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

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

This could happen due to unfortunate CFG coincidences.

PR19579

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

Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.

Patch by Alex McCarthy, with an extra test from me.

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

No functionality change.

Patch by Alex McCarthy!

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

If we're trying to get the zero element region of something that's not a region,
we should be returning UnknownVal, which is what ProgramState::getLValue will
do for us.

Patch by Alex McCarthy!

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

This will let us stage in the modeling of operator new. The -analyzer-config
opton 'c++-inline-allocators' is currently off by default.

Patch by Karthik Bhat!

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

Now that the CFG includes nodes for the destructors in a delete-expression,
process them in the analyzer using the same common destructor interface
currently used for local, member, and base destructors. Also, check for when
the value is known to be null, in which case no destructor is actually run.

This does not yet handle destructors for deleted /arrays/, which may need
more CFG work. It also causes a slight regression in the location of
double delete warnings; the double delete is detected at the destructor
call, which is implicit, and so is reported on the first access within the
destructor instead of at the 'delete' statement. This will be fixed soon.

Patch by Karthik Bhat!

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

This is an improved version of r186498. It enables ExprEngine to reason about
temporary object destructors.  However, these destructor calls are never
inlined, since this feature is still broken. Still, this is sufficient to
properly handle noreturn temporary destructors.

Now, the analyzer correctly handles expressions like "a || A()", and executes the
destructor of "A" only on the paths where "a" evaluted to false.

Temporary destructor processing is still off by default and one has to
explicitly request it by setting cfg-temporary-dtors=true.

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1259

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

Summary:
-fno-exceptions does not implicitly attach a nothrow specifier to every operator
new. Even in this mode, non-nothrow new must not return a null pointer. Failure
to allocate memory can be signalled by other means, or just by killing the
program. This behaviour is consistent with the compiler - even with
-fno-exceptions, the generated code never tests for null (and would segfault if
the opeator actually happened to return null).

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1528

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

Previously, we tried to avoid creating new temporary object regions if
the value to be materialized itself came from a temporary object region.
However, once we became more strict about lvalues vs. rvalues (months
ago), this optimization became dead code, because the input to this
function will always be an rvalue (i.e. a symbolic value or compound
value rather than a region, at least for structs).

This would be a nice optimization to keep, but removing it makes it
simpler to reason about temporary regions.

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

Previously, we asserted that whenever 'new' did not include a constructor
call, the type must be a non-record type. In C++11, however, uniform
initialization syntax (braces) allow 'new' to construct records with
list-initialization: "new Point{1, 2}".

Removing this assertion should be perfectly safe; the code here matches
what VisitDeclStmt does for regions allocated on the stack.

<rdar://problem/14403437>

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

Re-apply r184511, reverted in r184561, with the trivial default constructor
fast path removed -- it turned out not to be necessary here.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

<rdar://problem/14212563>

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

In order to make sure virtual base classes are always initialized once,
the AST contains initializers for the base class in /all/ of its
descendents, not just the immediate descendents. However, at runtime,
the most-derived object is responsible for initializing all the virtual
base classes; all the other initializers will be ignored.

The analyzer now checks to see if it's being called from another base
constructor, and if so does not perform virtual base initialization.

<rdar://problem/14236851>

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

Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.

This reverts r184511 / 98123284.

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

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.

<rdar://problem/14212563>

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

- Find the correct region to represent the first array element when
  constructing a CXXConstructorCall.
- If the array is trivial, model the copy with a primitive load/store.
- Don't warn about the "uninitialized" subscript in the AST -- we don't use
  the helper variable that Sema provides.

<rdar://problem/13091608>

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

No functionality change.

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

Evaluating a C++ new expression now includes generating an intermediate
ExplodedNode, and this node could very well represent a previously-
reachable state in the ExplodedGraph. If so, we can short-circuit the
rest of the evaluation.

Caught by the assertion a few lines later.

<rdar://problem/13510065>

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

+ Improved test coverage for cplusplus.NewDelete checker.

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

These types will not have a CXXConstructExpr to do the initialization for
them. Previously we just used a simple call to ProgramState::bindLoc, but
that doesn't trigger proper checker callbacks (like pointer escape).

Found by Anton Yartsev.

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

r175234 allowed the analyzer to model trivial copy/move constructors as
an aggregate bind. This commit extends that to trivial assignment
operators as well. Like the last commit, one of the motivating factors here
is not warning when the right-hand object is partially-initialized, which
can have legitimate uses.

<rdar://problem/13405162>

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

Normally, we need to look through derived-to-base casts when creating
temporary object regions (added in r175854). However, if the temporary
is a pointer (rather than a struct/class instance), we need to /preserve/
the base casts that have been applied.

This also ensures that we really do create a new temporary region when
we need to: MaterializeTemporaryExpr and lvalue CXXDefaultArgExprs.

Fixes PR15342, although the test case doesn't include the crash because
I couldn't isolate it.

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

Use Optional<CFG*> where invalid states were needed previously. In the one case
where that's not possible (beginAutomaticObjDtorsInsert) just use a dummy
CFGAutomaticObjDtor.

Thanks for the help from Jordan Rose & discussion/feedback from Ted Kremenek
and Doug Gregor.

Post commit code review feedback on r175796 by Ted Kremenek.

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

This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.

This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.

<rdar://problem/13265460> (part 2)

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

See r175462 for another example/more details.

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

This allows MemRegion and MemRegionManager to avoid asking over and over
again whether an class is a virtual base or a non-virtual base.

Minor optimization/cleanup; no functionality change.

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

Post-commit CR feedback from Jordan Rose regarding r175594.

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

See r175462 for another example/more details.

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

...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).

Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.

If this needs to be reverted again it will be punted to far in the future.

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

...again. The problem has not been fixed and our internal buildbot is still
getting hangs.

This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.

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

With the optimization in the previous commit, this should be safe again.

Originally applied in r173951, then reverted in r174069.

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