History log of /external/clang/test/Analysis/null-deref-path-notes.m
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/null-deref-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/null-deref-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/null-deref-path-notes.m
6f4160828db75f36b22a204da202723c592644f3 27-Feb-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value.

Consider this case:

int *p = 0;
p = getPointerThatMayBeNull();
*p = 1;

If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the
re-assignment.

This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.

<rdar://problem/13299738>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176201 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/null-deref-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/null-deref-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/null-deref-path-notes.m
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/null-deref-path-notes.m
e606e3d224d3fa8f6d4358ec66858d46754457a0 01-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Allow ObjC ivar lvalues where the base is nil.

By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.

This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.

This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164960 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/null-deref-path-notes.m
991bcb4370fe849603346ebbddc8dd47bc29d235 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.

Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:

PointObj *p = nil;
int *px = &p->_x; // should warn here
*px = 1;

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164442 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/null-deref-path-notes.m