aboutsummaryrefslogtreecommitdiff
path: root/test/Analysis/inlining/eager-reclamation-path-notes.cpp
AgeCommit message (Collapse)Author
2013-04-12[analyzer] Show "Returning from ..." note at caller's depth, not callee's.Jordan Rose
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
2013-04-12[analyzer] Don't emit extra context arrow after returning from an inlined call.Jordan Rose
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
2013-03-08[analyzer] Look for lvalue nodes when tracking a null pointer.Jordan Rose
r176010 introduced the notion of "interesting" lvalue expressions, whose nodes are guaranteed never to be reclaimed by the ExplodedGraph. This was used in bugreporter::trackNullOrUndefValue to find the region that contains the null or undef value being tracked. However, the /rvalue/ nodes (i.e. the loads from these lvalues that produce a null or undef value) /are/ still being reclaimed, and if we couldn't find the node for the rvalue, we just give up. This patch changes that so that we look for the node for either the rvalue or the lvalue -- preferring the former, since it lets us fall back to value-only tracking in cases where we can't get a region, but allowing the latter as well. <rdar://problem/13342842> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176737 91177308-0d34-0410-b5e6-96231b3b80d8