| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionality change.
llvm-svn: 173546
|
|
|
|
|
|
| |
This should be used for testing only. Path pruning is still on by default.
llvm-svn: 173545
|
|
|
|
|
|
|
| |
"Prune" is the term for eliminating pieces of a path that are not
relevant to the user. "Suppress" means don't show that path at all.
llvm-svn: 173544
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is to introduce a higher level "user mode" option for
different use scenarios. For example, if one wants to run the analyzer
for a small project each time the code is built, they would use
the "shallow" mode.
The user mode option will influence the default settings for the
lower-level analyzer options. For now, this just influences the ipa
modes, but we plan to find more optimal settings for them.
llvm-svn: 173386
|
|
|
|
|
|
|
|
|
| |
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
llvm-svn: 173385
|
|
|
|
| |
llvm-svn: 173384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
struct Wrapper { <-- 2. Calling default constructor for 'NonTrivial'.
NonTrivial m;
};
Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
After:
struct Wrapper {
NonTrivial m;
};
Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
^-- 2. Calling default constructor for 'NonTrivial'.
llvm-svn: 173067
|
|
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Properly use const_cast to fix a cast-away-const error.
llvm-svn: 172561
|
|
|
|
|
|
| |
This should fix cast-away-const warnings reported by David Greene.
llvm-svn: 172446
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This better reflects when callback is called and what the checkers
are relying on. (Both names meant the same pre-IPA.)
llvm-svn: 171432
|
|
|
|
|
|
|
| |
Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.
llvm-svn: 171364
|
|
|
|
| |
llvm-svn: 170903
|
|
|
|
| |
llvm-svn: 170832
|
|
|
|
|
|
|
|
|
|
| |
Instead of using several callbacks to identify the pointer escape event,
checkers now can register for the checkPointerEscape.
Converted the Malloc checker to use the new callback.
SimpleStreamChecker will be converted next.
llvm-svn: 170625
|
|
|
|
|
|
|
|
| |
accessible there.
This is plumbing needed for later functionality changes.
llvm-svn: 170488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 170238
|
|
|
|
|
|
| |
CXXDeleteExpr
llvm-svn: 170234
|
|
|
|
|
|
|
| |
Fixes a bug, where we were dropping the state modifications from the
checkBranchCondition checker callback.
llvm-svn: 170232
|
|
|
|
| |
llvm-svn: 170170
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This reduces canonicalization of ImmutableMaps. This reduces analysis time
of one heavy Objective-C file by another 1%.
llvm-svn: 169630
|
|
|
|
| |
llvm-svn: 169622
|
|
|
|
|
|
|
|
|
| |
ObjCMethodCall::getRuntimeDefinition().
The same queries can happen thousands of times. This reduces the analysis
time on one heavy Objective-C file by 2.4%.
llvm-svn: 169589
|
|
|
|
|
|
| |
avoiding over-eager canonicalization of clusters.
llvm-svn: 169586
|
|
|
|
| |
llvm-svn: 169581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bindings.
This reduces analysis time by 1.2% on one test case (Objective-C), but
also cleans up some of the code conceptually as well. We can possible
just make RegionBindingsRef -> RegionBindings, but I wanted to stage
things.
After this, we should revisit Jordan's optimization of not canonicalizing
the immutable AVL trees for the cluster bindings as well.
llvm-svn: 169571
|
|
|
|
|
|
|
|
| |
RegionStore."
Jordan and I discussed this, and we are going to do this another way.
llvm-svn: 169538
|
|
|
|
| |
llvm-svn: 169530
|
|
|
|
|
|
|
| |
'currStmt', 'CleanedState', and 'EntryNode' were being set, but only ever
used locally.
llvm-svn: 169529
|
|
|
|
| |
llvm-svn: 169528
|
|
|
|
|
|
|
|
|
| |
Previously we would search for the last statement, then back up to the
entrance of the block that contained that statement. Now, while we're
scanning for the statement, we just keep track of which blocks are being
exited (in reverse order).
llvm-svn: 169526
|
|
|
|
|
|
|
| |
This doesn't seem to make much of a difference in practice, but it does
have the potential to avoid a trip through the constraint manager.
llvm-svn: 169524
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever we touch a single bindings cluster multiple times, we can delay
canonicalizing it until the final access. This has some interesting
implications, in particular that we shouldn't remove an /empty/ cluster
from the top-level map until canonicalization.
This is good for a 2% speedup or so on the test case in
<rdar://problem/12810842>
llvm-svn: 169523
|
|
|
|
|
|
|
|
| |
This feature was probably intended to improve diagnostics, but was currently
only used when dumping the Environment. It shows what location a given value
was loaded from, e.g. when evaluating an LValueToRValue cast.
llvm-svn: 169522
|
|
|
|
|
|
|
|
| |
referenced_vars_iterator.
This is a nice conceptual cleanup.
llvm-svn: 169480
|