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/eager-reclamation-path-notes.cpp
|
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/eager-reclamation-path-notes.cpp
|
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/eager-reclamation-path-notes.cpp
|
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/eager-reclamation-path-notes.cpp
|
0183768813658d419e3124b576744b03ec8e9b55 |
|
09-Mar-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Look for lvalue nodes when tracking a null pointer. 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
/external/clang/test/Analysis/inlining/eager-reclamation-path-notes.cpp
|