| Age | Commit message (Collapse) | Author |
|---|
|
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reduces canonicalization of ImmutableMaps. This reduces analysis time
of one heavy Objective-C file by another 1%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ObjCMethodCall::getRuntimeDefinition().
The same queries can happen thousands of times. This reduces the analysis
time on one heavy Objective-C file by 2.4%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
avoiding over-eager canonicalization of clusters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169581 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
RegionStore."
Jordan and I discussed this, and we are going to do this another way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'currStmt', 'CleanedState', and 'EntryNode' were being set, but only ever
used locally.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169527 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169524 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169523 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169522 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
referenced_vars_iterator.
This is a nice conceptual cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169480 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169479 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169365 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will only check the direct ivar assignments in the annotated
methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169095 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Recursively prune some includes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169092 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/12759044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
generally by r168757.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168599 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168080 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168070 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168019 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This simplifies logic, fixes a bug, and adds a test case.
Thanks Jordan!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167813 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167790 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sean McBride!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change; this checker is only used for documentation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167522 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks Jordan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167438 91177308-0d34-0410-b5e6-96231b3b80d8
|
