History log of /external/clang/test/Analysis/inline-plist.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
0e2c34f92f00628d48968dfea096d36381f494cb 23-Mar-2015 Stephen Hines <srhines@google.com> Update aosp/master clang for rebase to r230699.

Change-Id: I6a546ab3d4ae37119eebb735e102cca4f80ab520
/external/clang/test/Analysis/inline-plist.c
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/inline-plist.c
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/inline-plist.c
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/inline-plist.c
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/inline-plist.c
9abf1b4577b75ffcc46afbdfb55de334f68f05c0 01-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Suppress paths involving a reference whose rvalue is null.

Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.

However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:

// From ClangSACheckersEmitter.cpp
recordGroupMap[group]->Checkers

In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)

We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.

<rdar://problem/13239854>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176371 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
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/inline-plist.c
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/inline-plist.c
b85cce094887ab5cf1c47acfe306e2fb1d3cfbb1 26-Oct-2012 Ted Kremenek <kremenek@apple.com> TrackConstraintBRVisitor and ConditionBRVisitor can emit similar
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.

Fixes <rdar://problem/12252783>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166728 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
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/inline-plist.c
53221da865144db0ba6bd89ab30bcf81de0fe5d2 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Track a null value back through FindLastStoreBRVisitor.

Also, tidy up the other tracking visitors so that they mark the right
things as interesting and don't do extra work.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164448 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
85e99373835fe1b4cec624bc48dc8dfe14c2a783 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Better path notes for null pointers passed as arguments.

Rather than saying "Null pointer value stored to 'foo'", we now say
"Passing null pointer value via Nth parameter 'foo'", which is much better.
The note is also now on the argument expression as well, rather than the
entire call.

This paves the way for continuing to track arguments back to their sources.

<rdar://problem/12211490>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164444 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
0187a1b8b9b2b7657de0ba8b0d4f67d30bec83e8 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Attempt (again) to stabilize the order of the emission of diagnostics
of the analyzer by using the FullProfile() of a PathDiagnostic
for ordering them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163455 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
ee04959f88e26ed38dccf4aed2ff10cad1f703c9 21-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] -analyzer-ipa=inlining is now the default. Remove it from tests.

The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlining tests run under whatever
mode is the default. However, there are some tests that depend on the
presence of C++ inlining, which still has some rough edges. These tests have
been explicitly marked as -analyzer-ipa=inlining in preparation for a new
mode that limits inlining to C functions and blocks. This will be the
default until the false positives for C++ have been brought down to
manageable levels.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162317 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
a64fae162fd1ca9398f6f4ecb27648d965e01587 08-Jun-2012 Anna Zaks <ganna@apple.com> [analyzer] Add experimental "issue hash" to the plist diagnostic.

CmpRuns.py can be used to compare issues from different analyzer runs.
Since it uses the issue line number to unique 2 issues, adding a new
line to the beginning of a file makes all issues in the file reported as
new.

The hash will be an opaque value which could be used (along with the
function name) by CmpRuns to identify the same issues. This way, we only
fail to identify the same issue from two runs if the function it appears
in changes (not perfect, but much better than nothing).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158180 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
7453a72cd0dcc70f29006ba488b743f078072bc7 06-Jun-2012 Ted Kremenek <kremenek@apple.com> PlistDiagnostics: force the ranges for control-flow edges to be single locations, forcing
adjacent edges to have compatible ranges. This simplifies the layout logic for some clients.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158028 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
7fa9b4f258636d89342eda28f21a986c8ac353b1 01-Jun-2012 Ted Kremenek <kremenek@apple.com> static analyzer: add inlining support for directly called blocks.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157833 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
11abcecc8c919673237cf37384290a1ef1943976 02-May-2012 Ted Kremenek <kremenek@apple.com> Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting
values through interesting expressions. This allows us to map from interesting values in a caller
to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA.

Fixes <rdar://problem/11327497>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155971 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
bd613137499b1d4c3b63dccd0aa21f6add243f4f 07-Apr-2012 Ted Kremenek <kremenek@apple.com> Rework ExprEngine::evalLoad and clients (e.g. VisitBinaryOperator) so that when we generate a new ExplodedNode
we use the same Expr* as the one being currently visited. This is preparation for transitioning to having
ProgramPoints refer to CFGStmts.

This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact,
as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for
the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra
argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but
it will look a lot cleaner when were start using CFGStmt* in the appropriate places.

As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed.
I have audited these, and they look reasonable.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154214 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
07189521a15d9c088216b943649cb9fe231cbb57 04-Apr-2012 Ted Kremenek <kremenek@apple.com> Include the "issue context" (e.g. function or method) where a static analyzer issue occurred in the plist output.

Fixes <rdar://problem/11004527>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154030 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
76b85acdd253cc33bbebde7f25fe50d908742e7d 15-Mar-2012 Ted Kremenek <kremenek@apple.com> Do not truncate expected plist output in FileCheck test.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152857 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
9373937945e1e075dfa08169eaccc1ad0b31f699 14-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Diagnostics: Supply Caller information even if the bug occurs
in the callee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152734 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
fc544e3d52c43746b1b273f38ec7d65461f0064a 13-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Call enter/exit diagnostic should refer to caller/callee,
respectively.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152676 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
e881efe78596a6ce9219237b737ced4adb1f8251 12-Mar-2012 Ted Kremenek <kremenek@apple.com> [analyzer] Include inlining call stack depth in plist output.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152584 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
66253352131e3e7a22b3bfd0e180607aa2bfb988 09-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Rework inlining related command line options.
- Remove -analyzer-inline-call.
- Add -analyzer-ipa=[none|inlining]
- Add -analyzer-inlining-mode to allow experimentation for
different performance tuning methods.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c
4ba86bc53bb280ba46a08459eda7d283d513b61f 02-Mar-2012 Ted Kremenek <kremenek@apple.com> [analyzer diagnostics] flush locations *before* popping the current path when visiting a CallEnter.

Fixes <rdar://problem/10967815>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151938 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline-plist.c