[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

llvm-svn: 152900

llvm-svn: 152868

[analyzer] Remove AggExprVisitor, a dead class that assisted in visiting C++ expressions with a "base object", because the CFG is now linearized.

The only use of AggExprVisitor was in #if 0 code (the analyzer's incomplete C++ support), so there is no actual behavioral change anyway.

llvm-svn: 152856

BugVisitor DiagnosticPieces.

When checkers create a DiagnosticPieceEvent, they can supply an extra
string, which will be concatenated with the call exit message for every
call on the stack between the diagnostic event and the final bug report.
(This is a simple version, which could be/will be further enhanced.)

For example, this is used in Malloc checker to produce the ",
which allocated memory" in the following example:

static char *malloc_wrapper() { // 2. Entered call from 'use'
    return malloc(12);    // 3. Memory is allocated
}

void use() {
    char *v;
    v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
        // 4. Returning from 'malloc_wrapper', which allocated memory
}                         // 5. Memory is never released; potential
memory leak

llvm-svn: 152837

(Why are we keeping all of this code around anyway? Say the word and I'll
start swinging the delete hammer.)

llvm-svn: 152749

in the callee.

llvm-svn: 152734

MaterializeTemporaryExpr.

llvm-svn: 152730

longer needed as the CFG is fully linearized.

llvm-svn: 152720

llvm-svn: 152677

respectively.

llvm-svn: 152676

inlining to be the reverse of their declaration.

This optimizes running time under inlining up to 20% since we do not
re-analyze the utility functions which are usually defined first in the
translation unit if they have already been analyzed while inlined into
the root functions.

llvm-svn: 152653

BFS should give slightly better performance. Ex: Suppose, we have two
roots R1 and R2. A callee function C is reachable through both. However,
C is not inlined when analyzing R1 due to inline stack depth limit. With
DFS, C will be analyzed as top level even though it would be analyzed as
inlined through R2. On the other hand, BFS could avoid analyzing C as
top level.

llvm-svn: 152652

collecting function Decls.

llvm-svn: 152651

AnalysisConsumer.

As a result:
 - We now analyze the C++ methods which are defined within the
class body. These were completely skipped before.

- Ensure that AST checkers are called on functions in the
order they are defined in the Translation unit.

llvm-svn: 152650

function.

llvm-svn: 152649

llvm-svn: 152648

llvm-svn: 152586

llvm-svn: 152584