History log of /external/clang/test/Analysis/inlining/path-notes.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
87d948ecccffea9e9e37d0d053b246e2d6d6c47b 04-Mar-2016 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master clang for rebase to r256229

http://b/26987366

Change-Id: I5d349c9843ea5c24d6e455956f8a446393b6873d
/external/clang/test/Analysis/inlining/path-notes.c
0e2c34f92f00628d48968dfea096d36381f494cb 23-Mar-2015 Stephen Hines <srhines@google.com> Update aosp/master clang for rebase to r230699.

Change-Id: I6a546ab3d4ae37119eebb735e102cca4f80ab520
/external/clang/test/Analysis/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.c
441625e6c7f8bf58e62a284ae1f855dafde31ec2 18-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Gain more precision retrieving the right SVal by specifying the type of the expression.

Thanks to Jordan for suggesting the fix.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179732 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
79d0cceb8847bfe6dc9da8eb2ea2f3c6bb73b813 16-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Address code review for r179395

Mostly refactoring + handle the nested fields by printing the innermost field only.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179572 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
9e2f5977a180ae927d05e844c65b8a7873be48a4 12-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer]Print field region even when the base region is not printable

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179395 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.c
cc5dbdae70c6eb2423921f52a35ba4686d2969cf 02-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Simple inline defensive checks suppression

Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.

This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.

There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?

Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.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/inlining/path-notes.c
7aba1171b32265b2206f3fa8f8886953051b58f5 28-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] If the last store into a region came from a function, step into it.

Previously, if we were tracking stores to a variable 'x', and came across this:

x = foo();

...we would simply emit a note here and stop. Now, we'll step into 'foo' and
continue tracking the returned value from there.

<rdar://problem/12114689>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162718 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
364b9f95fa47b0ca7f1cc694195f7a9953652f81 27-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Look through casts when trying to track a null pointer dereference.

Also, add comments to addTrackNullOrUndefValueVisitor.

Thanks for the review, Anna!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162695 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
23df2437a47ff129d2923ae325d42e79682a7f14 24-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] If we dereference a NULL that came from a function, show the return.

More generally, any time we try to track where a null value came from, we
should show if it came from a function. This usually isn't necessary if
the value is symbolic, but if the value is just a constant we previously
just ignored its origin entirely. Now, we'll step into the function and
recursively add a visitor to the returned expression.

<rdar://problem/12114609>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162563 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.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/inlining/path-notes.c
a801acd9773cacdbe16690269ecb47bd127440c5 06-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Add plist output checks for all four "path notes" tests.

No functionality change, but from now on, any new path notes should be
tested both with plain-text output (for ease of human auditing) and with
plist output (to ensure control flow and events are being correctly
represented in Xcode).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
685379965c1b105ce89cf4f6c60810932b7f4d0d 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] When a symbol is null, we should track its constraints.

Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161280 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c
b0e1badc2a9b8275b48dfb15c6907a282b949b02 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Flatten path diagnostics for text output like we do for HTML.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161279 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.c