History log of /external/clang/test/Analysis/inlining/false-positive-suppression.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
03af377b2755fb2ddb0621dea5dd91cd5fda631d 22-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix test to actually test what was intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177763 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.cpp
6a15f39a6bfd7a30085c5fa8f67d0b64b74b132a 15-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Look through ExprWhenCleanups when trying to track a NULL.

Silences a few false positives in LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177186 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.cpp
6022c4e17c0d2ad9c43ef6bc830d394b670a4705 13-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] BugReporter - more precise tracking of C++ references

When BugReporter tracks C++ references involved in a null pointer violation, we
want to differentiate between a null reference and a reference to a null pointer. In the
first case, we want to track the region for the reference location; in the second, we want
to track the null pointer.

In addition, the core creates CXXTempObjectRegion to represent the location of the
C++ reference, so teach FindLastStoreBRVisitor about it.

This helps null pointer suppression to kick in.

(Patch by Anna and Jordan.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176969 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.cpp
c236b7327f989c1e7fe6b08a188bfef86727513d 07-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {
int *p = 0;
return *p;
}

We already check that binds to reference regions don't create null references.
This patch checks that we don't create null references by returning, either.

<rdar://problem/13364378>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176601 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.cpp
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/inlining/false-positive-suppression.cpp
44ec3f00e64199667edf9f12c0f31f66916c95fe 26-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Track null object lvalues back through C++ method calls.

The expression 'a->b.c()' contains a call to the 'c' method of 'a->b'.
We emit an error if 'a' is NULL, but previously didn't actually track
the null value back through the 'a->b' expression, which caused us to
miss important false-positive-suppression cases, including
<rdar://problem/12676053>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173547 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.cpp