Recursively prune some includes.

llvm-svn: 169094

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.

llvm-svn: 169092

Correctly handle IntegralToBool casts in C++ in the static analyzer.  Fixes <rdar://problem/12759044>.

llvm-svn: 168843

llvm-svn: 168774

The stop-gap here is to just drop such objects when processing the InitListExpr.
We still need a better solution.

Fixes <rdar://problem/12755044>.

llvm-svn: 168757

This was also covered by <rdar://problem/12753384>.  The static analyzer
evaluates a CXXConstructExpr within an initializer expression and
RegionStore doesn't know how to handle the resulting CXXTempObjectRegion
that gets created.  We need a better solution than just dropping the
value, but we need to better understand how to implement the right
semantics here.

Thanks to Jordan for his help diagnosing the behavior here.

llvm-svn: 168741

The AllocaRegion did not have the superRegion (based on LocationContext)
as part of it's hash. As a consequence, the AllocaRegions from
different frames were uniqued to be the same region.

llvm-svn: 168599

llvm-svn: 168500

In code like this:

void foo() {
     bar();
     baz();
}

...the location for the call to 'bar()' was being used as a backup location
for the call to 'baz()'. This is fine unless the call to 'bar()' is deemed
uninteresting and that part of the path deleted.

(This looks like a logic error as well, but in practice the only way 'baz()'
could have an invalid location is if the entire body of 'foo()' is
synthesized, meaning the call to 'bar()' will be using the location of the
call to 'foo()' anyway. Nevertheless, the new version better matches the
intent of the code.)

Found by Matt Beaumont-Gay using ASan. Thanks, Matt!

llvm-svn: 168080

This fixes a few cases where we'd emit path notes like this:

  +---+
 1|   v
  p = malloc(len);
  ^   |2
  +---+

In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.

llvm-svn: 168070

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168069

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168068

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168067

This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.

This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.

llvm-svn: 168066

We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.

Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).

Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.

<rdar://problem/12657843>

llvm-svn: 168019

This simplifies logic, fixes a bug, and adds a test case.
Thanks Jordan!

llvm-svn: 167868

and other functions.

When these functions return null, the pointer is not freed by
them/ownership is not transfered. So we should allow the user to free
the pointer by calling another function when the return value is NULL.

llvm-svn: 167813

llvm-svn: 167790

conditions.

The adjustment is needed only in case of dynamic dispatch performed by
the analyzer - when the runtime declaration is different from the static
one.

Document this explicitly in the code (by adding a helper). Also, use
canonical Decls to avoid matching against the case where the definition
is different from found declaration.

This fix suppresses the testcase I added in r167762, so add another
testcase to make sure we do test commit r167762.

llvm-svn: 167780

Suppresses a leak false positive (radar://12663777).

In addition, we'll need to rewrite the adjustReturnValue() method not to
return UnknownVal by default, but rather assert in cases we cannot
handle. To make it possible, we need to correctly handle some of the
edge cases we already know about.

llvm-svn: 167762

Previously, RegionStore was being VERY conservative in saying that because
p[i].x and p[i].y have a concrete base region of 'p', they might overlap.
Now, we check the chain of fields back up to the base object and check if
they match.

This only kicks in when dealing with symbolic offset regions because
RegionStore's "base+offset" representation of concrete offset regions loses
all information about fields. In cases where all offsets are concrete
(s.x and s.y), RegionStore will already do the right thing, but mixing
concrete and symbolic offsets can cause bindings to be invalidated that
are known to not overlap (e.g. p[0].x and p[i].y).
This additional refinement is tracked by <rdar://problem/12676180>.

<rdar://problem/12530149>

llvm-svn: 167654

Patch by Sean McBride!

llvm-svn: 167537

No functionality change; this checker is only used for documentation.

llvm-svn: 167522

llvm-svn: 167439

Thanks Jordan.

llvm-svn: 167438

As Anna pointed out, ProgramStateTrait.h is a relatively obscure header,
and checker writers may not know to look there to add their own custom
state.

The base macro that specializes the template remains in ProgramStateTrait.h
(REGISTER_TRAIT_WITH_PROGRAMSTATE), which allows the analyzer core to keep
using it.

llvm-svn: 167385

0 (as nullptr) is incompatible to pointer in type matching on msvc.

llvm-svn: 167355

This will simplify checkers that need to register for leaks. Currently,
they have to register for both: check dead and check end of path.

I've modified the SymbolReaper to consider everything on the stack dead
if the input StackLocationContext is 0.

(This is a bit disruptive, so I'd like to flash out all the issues
asap.)

llvm-svn: 167352

llvm-svn: 167351

Node builders should manage the nodes, not the context.

llvm-svn: 167350

llvm-svn: 167340

llvm-svn: 167339

These are CallEvent-equivalents of helpers already accessible in
CheckerContext, as part of making it easier for new checkers to be written
using CallEvent rather than raw CallExprs.

llvm-svn: 167338

Also, Decls already carry a pointer to the ASTContext, so there's no need
to pass an extra argument to the predicate.

llvm-svn: 167337

llvm-svn: 167316

Add FIXMEs for the traits visible from multiple translation units.
Currently the macros hide their key types in an anonymous namespace.

llvm-svn: 167277

Also, move the REGISTER_*_WITH_PROGRAMSTATE macros to ProgramStateTrait.h.

This doesn't get rid of /all/ explicit uses of ProgramStatePartialTrait,
but it does get a lot of them.

llvm-svn: 167276

No functionality change.

llvm-svn: 167275

llvm-svn: 167189

No functionality change.

llvm-svn: 167187