History log of /external/clang/test/Analysis/inlining/inline-defensive-checks.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
4b69feb6d90eb120d04f5d54f6b28cc295a46098 06-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Fix null tracking for the given test case, by using the proper state and removing redundant code.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178933 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/inline-defensive-checks.cpp
a4bb4f6ca8dd31ad96cb9526a5abe1273f18ff40 14-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Change the way in which IDC Visitor decides to kick in and make sure it attaches in the given edge case

In the test case below, the value V is not constrained to 0 in ErrorNode but it is in node N.
So we used to fail to register the Suppression visitor.

We also need to change the way we determine that the Visitor should kick in because the node N belongs to
the ExplodedGraph and might not be on the BugReporter path that the visitor sees. Instead of trying to match the node,
turn on the visitor when we see the last node in which the symbol is ‘0’.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177121 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/inline-defensive-checks.cpp
0415998dd77986630efe8f1aed633519cc41e1f3 09-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Make Suppress IDC checker aware that it might not start from the same node it was registered at

The visitor used to assume that the value it’s tracking is null in the first node it examines. This is not true.
If we are registering the Suppress Inlined Defensive checks visitor while traversing in another visitor
(such as FindlastStoreVisitor). When we restart with the IDC visitor, the invariance of the visitor does
not hold since the symbol we are tracking no longer exists at that point.

I had to pass the ErrorNode when creating the IDC visitor, because, in some cases, node N is
neither the error node nor will be visible along the path (we had not finalized the path at that point
and are dealing with ExplodedGraph.)

We should revisit the other visitors which might not be aware that they might get nodes, which are
later in path than the trigger point.

This suppresses a number of inline defensive checks in JavaScriptCore.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176756 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/inline-defensive-checks.cpp