| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Entered call from 'test' (at "=default" or 'Foo' declaration)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)
After:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)
This only affects the plist diagnostics; this note is never shown in the
other diagnostics.
llvm-svn: 172915
|
| |
|
|
|
|
|
| |
with other auxilliary test inputs and simplify the identification of
inputs to tests.
llvm-svn: 172890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppress the warning by just not emitting the report. The sink node
would get generated, which is fine since we did reach a bad state.
Motivation
Due to the way code is structured in some of these macros, we do not
reason correctly about it and report false positives. Specifically, the
following loop reports a use-after-free. Because of the way the code is
structured inside of the macro, the analyzer assumes that the list can
have cycles, so you end up with use-after-free in the loop, that is
safely deleting elements of the list. (The user does not have a way to
teach the analyzer about shape of data structures.)
SLIST_FOREACH_SAFE(item, &ctx->example_list, example_le, tmpitem) {
if (item->index == 3) { // if you remove each time, no complaints
assert((&ctx->example_list)->slh_first == item);
SLIST_REMOVE(&ctx->example_list, item, example_s, example_le);
free(item);
}
}
llvm-svn: 172883
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Examples:
Calling implicit default constructor for Foo
Calling defaulted move constructor for Foo
Calling copy constructor for Foo
Calling implicit destructor for Foo
Calling defaulted move assignment operator for Foo
Calling copy assignment operator for Foo
llvm-svn: 172833
|
| |
|
|
|
|
|
|
| |
Examples:
Calling constructor for 'Foo'
Entered call from 'Foo::create'
llvm-svn: 172832
|
| |
|
|
| |
llvm-svn: 172766
|
| |
|
|
|
|
| |
assignment
llvm-svn: 172597
|
| |
|
|
| |
llvm-svn: 172596
|
| |
|
|
|
|
|
|
|
|
|
| |
This was previously added to support -[NSAutoreleasePool drain], which
behaves like -release under non-GC and "please collect" under GC. We're
not currently modeling the autorelease pool stack, though, so we can
just take this out entirely.
Fixes PR14927.
llvm-svn: 172444
|
| |
|
|
|
|
| |
Fixes PR 14634 and <rdar://problem/12903080>.
llvm-svn: 172274
|
| |
|
|
|
|
|
| |
Fixes assertion failure reported in PR 14635 and
<rdar://problem/12902945> respectively.
llvm-svn: 172263
|
| |
|
|
|
|
| |
can be fixed
llvm-svn: 172170
|
| |
|
|
|
|
| |
This will get rid of some false positives as well as false negatives.
llvm-svn: 172169
|
| |
|
|
| |
llvm-svn: 172168
|
| |
|
|
|
|
|
|
|
|
|
|
| |
assertions.
To ensure that custom assertions/conditional would also be supported,
just check if the ivar that needs to be invalidated or set to nil is
compared against 0.
Unfortunately, this will not work for code containing 'assert(IvarName)'
llvm-svn: 172147
|
| |
|
|
|
|
|
|
| |
In some cases, we just pick any ivar that needs invalidation and attach
the warning to it. Picking the first from DenseMap of pointer keys was
triggering non-deterministic output.
llvm-svn: 172134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restructured the checker so that it could easily find two new classes of
issues:
- when a class contains an invalidatable ivar, but no declaration of an
invalidation method
- when a class contains an invalidatable ivar, but no definition of an
invalidation method in the @implementation.
The second case might trigger some false positives, for example, when
the method is defined in a category.
llvm-svn: 172104
|
| |
|
|
|
|
|
|
| |
imaginary and real parts yet.
Fixes false positive reported in <rdar://problem/12964481>.
llvm-svn: 171987
|
| |
|
|
|
|
|
| |
This makes us more optimistic when matching reports in a changing code
base. Addresses Jordan's feedback for r171825.
llvm-svn: 171884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.
Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.
We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.
llvm-svn: 171825
|
| |
|
|
|
|
| |
This gives more flexibility to what could be stored as issue_hash.
llvm-svn: 171824
|
| |
|
|
|
|
|
|
|
| |
Better handle the blacklisting of known bad deallocators when symbol
escapes through a call to CFStringCreateWithBytesNoCopy.
Addresses radar://12702952.
llvm-svn: 171770
|
| |
|
|
|
|
|
|
|
| |
When a property is "inherited" through both a parent class and directly
through a protocol, we should not require the child to invalidate it
since the backing ivar belongs to the parent class.
(Fixes radar://12913734)
llvm-svn: 171769
|
| |
|
|
|
|
|
|
|
| |
First check only wrapped with i==8, second wrapped at i==2,8,18,28,...
This fix restores the intended behavior: i==8,18,28,...
Found with -fsanitize=integer.
llvm-svn: 171718
|
| |
|
|
| |
llvm-svn: 171440
|
| |
|
|
|
|
|
| |
This better reflects when callback is called and what the checkers
are relying on. (Both names meant the same pre-IPA.)
llvm-svn: 171432
|
| |
|
|
|
|
|
|
| |
objc_no_direct_instance_variable_assignment.
Fixes <rdar://problem/12927551>.
llvm-svn: 170971
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deterministic.
Commit message for r170826:
[analyzer] Traverse the Call Graph in topological order.
Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
tracking of nodes that are "top level" or global. This information is
not used and can be obtained from the Decls stored inside
CallGraphNodes.
Instead of existing ordering hacks, analyze the functions in topological
order over the Call Graph.
Together with the addition of devirtualizable ObjC message sends and
blocks to the call graph, this gives around 6% performance improvement
on several large ObjC benchmarks.
llvm-svn: 170906
|
| |
|
|
|
|
|
|
| |
./bin/clang -cc1 -internal-isystem /home/espindola/llvm/build/lib/clang/3.3/include/ -analyze -analyzer-checker=debug.DumpCallGraph /home/espindola/llvm/clang/test/Analysis/debug-CallGraph.c -fblocks
changes in each run.
llvm-svn: 170829
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
tracking of nodes that are "top level" or global. This information is
not used and can be obtained from the Decls stored inside
CallGraphNodes.
Instead of existing ordering hacks, analyze the functions in topological
order over the Call Graph.
Together with the addition of devirtualizable ObjC message sends and
blocks to the call graph, this gives around 6% performance improvement
on several large ObjC benchmarks.
llvm-svn: 170826
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to also remove a trailing space if possible.
For example, removing '__bridge' from:
i = (__bridge I*)p;
should result in:
i = (I*)p;
not:
i = ( I*)p;
rdar://11314821
llvm-svn: 170764
|
| |
|
|
|
|
| |
Fixes <rdar://problem/12887356>.
llvm-svn: 170724
|
| |
|
|
| |
llvm-svn: 170362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performance heuristic
After inlining a function with more than 13 basic blocks 32 times, we
are not going to inline it anymore. The idea is that inlining large
functions leads to drastic performance implications. Since the function
has already been inlined, we know that we've analyzed it in many
contexts.
The following metrics are used:
- Large function is a function with more than 13 basic blocks (we
should switch to another metric, like cyclomatic complexity)
- We consider that we've inlined a function many times if it's been
inlined 32 times. This number is configurable with -analyzer-config
max-times-inline-large=xx
This heuristic addresses a performance regression introduced with
inlining on one benchmark. The analyzer on this benchmark became 60
times slower with inlining turned on. The heuristic allows us to analyze
it in 24% of the time. The performance improvements on the other
benchmarks I've tested with are much lower - under 10%, which is
expected.
llvm-svn: 170361
|
| |
|
|
|
|
|
|
| |
We now check a few methods for UIResponder, NSResponder, and NSDocument.
Patch by Julian Mayer!
llvm-svn: 170089
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a Band-Aid fix to a false positive, where we complain about not
initializing self to [super init], where self is not coming from the
init method, but is coming from the caller to init.
The proper solution would be to associate the self and it's state with
the enclosing init.
llvm-svn: 170059
|
| |
|
|
|
|
|
|
|
|
| |
We don't handle array destructors correctly yet, but we now apply the same
hack (explicitly destroy the first element, implicitly invalidate the rest)
for multidimensional arrays that we already use for linear arrays.
<rdar://problem/12858542>
llvm-svn: 170000
|
| |
|
|
|
|
|
|
|
| |
inlined.
Fixes a false positive that occurs if a user writes their own
initWithBytesNoCopy:freeWhenDone wrapper.
llvm-svn: 169795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
top level.
This heuristic is already turned on for non-ObjC methods
(inlining-mode=noredundancy). If a method has been previously analyzed,
while being inlined inside of another method, do not reanalyze it as top
level.
This commit applies it to ObjCMethods as well. The main caveat here is
that to catch the retain release errors, we are still going to reanalyze
all the ObjC methods but without inlining turned on.
Gives 21% performance increase on one heavy ObjC benchmark, which
suffered large performance regressions due to ObjC inlining.
llvm-svn: 169639
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the case where the analyzer tries to print out source locations
for code within a synthesized function body, which of course does not have
a valid source location. The previous fix attempted to do this during
diagnostic path pruning, but some diagnostics have pruning disabled, and
so any diagnostic with a path that goes through a synthesized body will
either hit an assertion or emit invalid output.
<rdar://problem/12657843> (again)
llvm-svn: 169631
|
| |
|
|
|
|
|
|
|
| |
Previously we made three passes over the set of dead symbols, and removed
them from the state /twice/. Now we combine the autorelease pass and the
symbol death pass, and only have to remove the bindings for the symbols
that leaked.
llvm-svn: 169527
|
| |
|
|
|
|
|
|
|
| |
BlockDataRegion. Fixes <rdar://problem/12415065>.
We still need to do a recursive walk to determine all static/global variables
referenced by a block, which is needed for region invalidation.
llvm-svn: 169481
|
| |
|
|
|
|
| |
up after itself if it failed.
llvm-svn: 169356
|
| |
|
|
|
|
|
| |
This will only check the direct ivar assignments in the annotated
methods.
llvm-svn: 169349
|
| |
|
|
|
|
| |
<rdar://problem/12759044>.
llvm-svn: 168843
|
| |
|
|
|
|
|
|
|
|
|
| |
initializer.
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
|
| |
|
|
|
|
| |
Thanks for the original catch in r168303, Takumi.
llvm-svn: 168671
|
| |
|
|
|
|
|
|
| |
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: 168303
|