console, and leave it up to PathDiagnosticConsumer to unique reports with the shortest path.

llvm-svn: 153987

Store this info inside the function summary generated for all analyzed
functions. This is useful for coverage stats and can be helpful for
analyzer state space search strategies.

llvm-svn: 153923

Fix another false positive in RegionStore involving doing loads from symbolic offsets.  We still don't
properly reason about such accesses, but we shouldn't emit bogus "uninitialized value" warnings
either.  Fixes <rdar://problem/11127008>.

llvm-svn: 153913

Fix potential null dereference in the static analyzer when inlining a call that has already been inlined.  Unfortunately I have no test case.

llvm-svn: 153900

Analyzer: Store BugReports directly in a ilist instead of adding another layer of inderection with std::list

llvm-svn: 153847

Fixes a false positive (radar://11152419). The current solution of
adding the info into 3 places is quite ugly. Pending a generic pointer
escapes callback.

llvm-svn: 153731

count.

This is an optimization for "retry without inlining" option. Here, if we
failed to inline a function due to reaching the basic block max count,
we are going to store this information and not try to inline it
again in the translation unit. This can be viewed as a function summary.

On sqlite, with this optimization, we are 30% faster then before and
cover 10% more basic blocks (partially because the number of times we
reach timeout is decreased by 20%).

llvm-svn: 153730

llvm-svn: 153591

retry without inlining.

(+ other minor cleanups)

llvm-svn: 153581

the root function.

(This is a bit cleaner then using the StackFrame.)

llvm-svn: 153580

llvm-svn: 153568

The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.

This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.

This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement. 

The option is turned off by default for now.

llvm-svn: 153534

Report root function name with exhausted block diagnostic.

Also, use stack frames, not just any location context when checking if
the basic block is in the same context.

llvm-svn: 153532

analyzes.

(This method can be called twice on the same function.)

llvm-svn: 153531

assigned to a struct.  This is fallout from inlining results, which expose
far more patterns where people stuff CF objects into structs and pass them
around (and we can reason about it).  The problem is that we don't have
a general way to detect when values have escaped, so as an intermediate step
we need to eagerly prune out such tracking.

Fixes <rdar://problem/11104566>.

llvm-svn: 153489

llvm-svn: 153453

[analyzer] Tighten up the realloc() failure path note generation...make sure we get the right realloc()!

llvm-svn: 153370

[analyzer] Restart path diagnostic generation if any of the visitors change the report configuration while walking the path.

This required adding a change count token to BugReport, but also allowed us to ditch ImmutableList as the BugReporterVisitor data type.

Also, remove the hack from MallocChecker, now that visitors appear in the opposite order. This is not exactly a fix, but the common case -- custom diagnostics after generic ones -- is now the default behavior.

llvm-svn: 153369

[analyzer] Add a clone() method to BugReporterVisitor, so that we'll be able to reset diagnostic generation.

llvm-svn: 153368

Avoid applying retain/release effects twice in RetainCountChecker when a function call was inlined (i.e., we do not need to apply summaries in such cases).

llvm-svn: 153309

llvm-svn: 153302

llvm-svn: 153283

llvm-svn: 153281

llvm-svn: 153280

(Stats Checker).

llvm-svn: 153279

"Teach" RetainCountChecker about dispatch_set_context, which can indirectly free its argument later.  Fixes <rdar://problem/11059275>.

llvm-svn: 153244

llvm-svn: 153232

llvm-svn: 153220

Specifically, we use the last store of the leaked symbol in the leak diagnostic.
(No support for struct fields since the malloc checker doesn't track those
yet.)

+ Infrastructure to track the regions used in store evaluations.
This approach is more precise than iterating the store to
obtain the region bound to the symbol, which is used in RetainCount
checker. The region corresponds to what is uttered in the code in the
last store and we do not rely on the store implementation to support
this functionality.

llvm-svn: 153212

So that others could use it as well. No functionality change.

llvm-svn: 153211

[analyzer] Mark a failed-realloc's result as an interesting symbol between the realloc call and the null check, so we get nicer path notes. Fixes a regression introduced by the diagnostic pruning added in r152361.

This is accomplished by calling markInteresting /during/ path diagnostic generation, and as such relies on deterministic ordering of BugReporterVisitors -- namely, that BugReporterVisitors are run in /reverse/ order from how they are added. (Right now that's a consequence of storing visitors in an ImmutableList, where new items are added to the front.) It's a little hacky, but it works for now.

I think this is the best we can do without storing the relation between the old and new symbols, and that would be a hit whether or not there ends up being an error.

llvm-svn: 153010

[analyzer] Use a FoldingSet to cache simple RetainSummary instances, rather than explicitly keeping DoNothing and StopTracking summaries and nothing else.

I tried to test the effects of this change on memory usage and run time, but what I saw on retain-release.m was indistinguishable from noise (debug and release builds). Even so, some caveman profiling showed 101 cache hits that we would have generated new summaries for before (i.e. not default or stop summaries), and the more code we analyze, the more memory we should save.

Maybe we should have a standard project for benchmarking the retain count checker's memory and time?

llvm-svn: 153007

[analyzer] Unify retain-count summary generation for class and instance methods. No functionality change.

llvm-svn: 153001

The cocoa::deriveNamingConventions helper is just using method families anyway now, and the way RetainSummaryTemplate works means we're allocating an extra summary for every method with a relevant family.

Also, fix RetainSummaryTemplate to do the right thing w/r/t annotating an /existing/ summary. This was probably the real cause of <rdar://problem/10824732> and the fix in r152448.

llvm-svn: 152998

llvm-svn: 152982

[analyzer] Don't claim an object was returned with +1 retain count before counting autoreleases. Fixes PR10376.

(Also, 80-column violations.)

llvm-svn: 152976

Do not display the standard "Returning from 'foo'", when a stack hint is
available.

llvm-svn: 152964

The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.

For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"


(We are yet to handle cases when the symbol is a field in a struct or
an array element.)

llvm-svn: 152962

llvm-svn: 152961

number of steps in the work list.

llvm-svn: 152960