| d8188f8ad5d584b5f6e1f58e5a4882586cc630d4 |
|
02-Aug-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't process autorelease counts in synthesized function bodies.
We process autorelease counts when we exit functions, but if there's an
issue in a synthesized body the report will get dropped. Just skip the
processing for now and let it get handled when the caller gets around to
processing autoreleases.
(This is still suboptimal: objects autoreleased in the caller context
should never be warned about when exiting a callee context, synthesized
or not.)
Second half of <rdar://problem/14611722>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187625 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| cd007b18ba218925923a82ad4462fecf903f4a93 |
|
02-Aug-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Silently drop all reports within synthesized bodies.
Much of our diagnostic machinery is set up to assume that the report
end path location is valid. Moreover, the user may be quite confused
when something goes wrong in our BodyFarm-synthesized function bodies,
which may be simplified or modified from the real implementations.
Rather than try to make this all work somehow, just drop the report so
that we don't try to go on with an invalid source location.
Note that we still handle reports whose /paths/ go through invalid
locations, just not those that are reported in one.
We do have to be careful not to lose warnings because of this.
The impetus for this change was an autorelease being processed within
the synthesized body, and there may be other possible issues that are
worth reporting in some way. We'll take these as they come, however.
<rdar://problem/14611722>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187624 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 048eeea6852043990c87e52938b53b5337bd098e |
|
04-Jun-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Enable the new edge algorithm by default.
...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183165 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| b9814c867e69d542ea6b90c756814dab462019c7 |
|
24-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Fix test for r182677.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182678 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| d474da062565596015558856333423199aed5eb1 |
|
24-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Treat analyzer-synthesized function bodies like implicit bodies.
When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.
By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.
<rdar://problem/13978414>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182677 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| ef202c35b37c137e32fe30f4453915b6d3b525d7 |
|
14-May-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Refactor: address Jordan’s code review of r181738.
(Modifying the checker to record that the values are no longer nil will be done separately.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181744 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| dcd6224911e234ab3657b7d0b79a2add1ae4fdd8 |
|
03-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Fix trackNullOrUndef when tracking args that have nil receivers.
There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a nil receiver, we thought we
were still looking at an argument to the original call.
Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.
Noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180996 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 0f8579274a010f360a371b53101859d9d6052314 |
|
24-Apr-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse
The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.
The location of the warning reported in text/command line output format will now match that of the plist file.
There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 62fba4f08af16ff17b5cbe8816061349504317e4 |
|
18-Apr-2013 |
Ted Kremenek <kremenek@apple.com> |
[analyzer] Refine 'nil receiver' diagnostics to mention the name of the method not called.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179776 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 7be2245487f9cd7d04f013db92280d9ccd323586 |
|
12-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Show "Returning from ..." note at caller's depth, not callee's.
Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
After:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.
This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.
<rdar://problem/13634363>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 3ea09a802f973c2726b2a489ae08a4bded93410b |
|
12-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't emit extra context arrow after returning from an inlined call.
In this code
int getZero() {
return 0;
}
void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}
}
we generate these arrows:
+-----------------+
| v
int problem = 1 / getZero();
^ |
+---+
where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.
* Arguably the best location for the division is the '/', but that's a
different problem.
<rdar://problem/13326040>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179350 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 4238f41d484729aca260140fbbc53a68769bf60a |
|
26-Feb-2013 |
Ted Kremenek <kremenek@apple.com> |
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion.
Fixes PR15358 and <rdar://problem/13295437>.
Along the way, shorten path diagnostics that say "Variable 'x'" to just
be "'x'". By the context, it is obvious that we have a variable,
and so this just consumes text space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176115 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| c1c6a4981a4b50476d71c88f8dac81a1430885ed |
|
08-Jan-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Plist: change the type of issue_hash from int to string.
This gives more flexibility to what could be stored as issue_hash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171824 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| afa7cae15b117c4b75794c6c32424953d94b4359 |
|
07-Dec-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Fix r168019 to work with unpruned paths as well.
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
/external/clang/test/Analysis/inlining/path-notes.m
|
| 368f3b070e8cb657a65bfa443d60256676d269e7 |
|
15-Nov-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Make sure calls in synthesized functions have valid path locations.
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
/external/clang/test/Analysis/inlining/path-notes.m
|
| b9d4e5e3bb235f1149e99d3c833ff7cb3474c9f1 |
|
22-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Suppress bugs whose paths go through the return of a null pointer.
This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.
This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.
I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164449 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|
| 6686b6694a7998623550ff6529f2f53bfee94328 |
|
22-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Look through OpaqueValueExprs when tracking a nil value.
This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164445 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.m
|