maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/inlining/path-notes.m

1050 lines
45 KiB
Mathematica
Raw Normal View History

[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-output=text -analyzer-config suppress-null-return-paths=false -fblocks -verify %s
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-output=plist-multi-file -analyzer-config suppress-null-return-paths=false -fblocks %s -o %t.plist
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// RUN: FileCheck --input-file=%t.plist %s
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
typedef struct dispatch_queue_s *dispatch_queue_t;
typedef void (^dispatch_block_t)(void);
void dispatch_sync(dispatch_queue_t, dispatch_block_t);
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
@interface Test
@property int *p;
@end
int *getZeroIfNil(Test *x) {
return x.p;
[analyzer] Refine 'nil receiver' diagnostics to mention the name of the method not called. llvm-svn: 179776
2013-04-19 01:44:15 +08:00
// expected-note@-1 {{'p' not called because the receiver is nil}}
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// expected-note@-2 {{Returning null pointer}}
}
void testReturnZeroIfNil() {
*getZeroIfNil(0) = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Calling 'getZeroIfNil'}}
// expected-note@-2 {{Passing nil object reference via 1st parameter 'x'}}
// expected-note@-3 {{Returning from 'getZeroIfNil'}}
// expected-note@-4 {{Dereference of null pointer}}
}
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
int testDispatchSyncInlining() {
extern dispatch_queue_t globalQueue;
__block int x;
// expected-note@+2 {{Calling 'dispatch_sync'}}
// expected-note@+1 {{Returning from 'dispatch_sync'}}
dispatch_sync(globalQueue, ^{
// expected-note@7 {{Calling anonymous block}}
x = 0;
// expected-note@-1 {{The value 0 is assigned to 'x'}}
// expected-note@7 {{Returning to caller}}
});
return 1 / x; // expected-warning{{Division by zero}}
// expected-note@-1 {{Division by zero}}
}
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
int testDispatchSyncInliningNoPruning(int coin) {
// This tests exactly the same case as above, except on a bug report where
// path pruning is disabled (an uninitialized variable capture).
// In this case
extern dispatch_queue_t globalQueue;
__block int y;
// expected-note@+1 {{Calling 'dispatch_sync'}}
dispatch_sync(globalQueue, ^{
// expected-note@7 {{Calling anonymous block}}
int x;
[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. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-1 {{'x' declared without an initial value}}
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
^{ y = x; }(); // expected-warning{{Variable 'x' is uninitialized when captured by block}}
[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. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-1 {{'x' is uninitialized when captured by block}}
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
});
return y;
}
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK: <key>diagnostics</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Passing nil object reference via 1st parameter &apos;x&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Passing nil object reference via 1st parameter &apos;x&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>15</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling &apos;getZeroIfNil&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling &apos;getZeroIfNil&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;testReturnZeroIfNil&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;testReturnZeroIfNil&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
[analyzer] Refine 'nil receiver' diagnostics to mention the name of the method not called. llvm-svn: 179776
2013-04-19 01:44:15 +08:00
// CHECK-NEXT: <string>&apos;p&apos; not called because the receiver is nil</string>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Refine 'nil receiver' diagnostics to mention the name of the method not called. llvm-svn: 179776
2013-04-19 01:44:15 +08:00
// CHECK-NEXT: <string>&apos;p&apos; not called because the receiver is nil</string>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>15</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning null pointer</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Returning null pointer</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
[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> llvm-svn: 179351
2013-04-12 08:44:17 +08:00
// CHECK-NEXT: <key>depth</key><integer>0</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning from &apos;getZeroIfNil&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Returning from &apos;getZeroIfNil&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>15</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>22</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testReturnZeroIfNil</string>
[analyzer] Plist: change the type of issue_hash from int to string. This gives more flexibility to what could be stored as issue_hash. llvm-svn: 171824
2013-01-08 08:25:22 +08:00
// CHECK-NEXT: <key>issue_hash</key><string>1</string>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>line</key><integer>21</integer>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>30</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>30</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>15</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>41</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>7</integer>
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;testDispatchSyncInlining&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;testDispatchSyncInlining&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>7</integer>
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling anonymous block</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling anonymous block</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>2</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>38</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>38</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>38</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>38</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>38</integer>
// CHECK-NEXT: <key>col</key><integer>9</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>2</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>The value 0 is assigned to &apos;x&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>The value 0 is assigned to &apos;x&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>7</integer>
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
[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> llvm-svn: 179351
2013-04-12 08:44:17 +08:00
// CHECK-NEXT: <key>depth</key><integer>1</integer>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning to caller</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Returning to caller</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>41</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
[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> llvm-svn: 179351
2013-04-12 08:44:17 +08:00
// CHECK-NEXT: <key>depth</key><integer>0</integer>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Returning from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>36</integer>
// CHECK-NEXT: <key>col</key><integer>15</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>14</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Division by zero</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Division by zero</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Division by zero</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Division by zero</string>
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testDispatchSyncInlining</string>
[analyzer] Plist: change the type of issue_hash from int to string. This gives more flexibility to what could be stored as issue_hash. llvm-svn: 171824
2013-01-08 08:25:22 +08:00
// CHECK-NEXT: <key>issue_hash</key><string>14</string>
[analyzer] Make sure calls in synthesized functions have valid path locations. We do this by using the "most recent" good location: if a synthesized function 'A' calls another function 'B', the path notes for the call to 'B' will be placed at the same location as the path note for calling 'A'. Similarly, the call to 'A' will have a note saying "Entered call from...", and now we just don't emit that (since the user doesn't have a body to look at anyway). Previously, we were doing this for the "Calling..." notes, but not for the "Entered call from..." or "Returning to caller". This caused a crash when the path entered and then exiting a call within a synthesized body. <rdar://problem/12657843> llvm-svn: 168019
2012-11-15 10:07:23 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>43</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>51</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>51</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>15</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>7</integer>
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;testDispatchSyncInliningNoPruning&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;testDispatchSyncInliningNoPruning&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>7</integer>
// CHECK-NEXT: <key>col</key><integer>1</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling anonymous block</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling anonymous block</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>2</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;dispatch_sync&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>56</integer>
// CHECK-NEXT: <key>col</key><integer>30</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>9</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>2</integer>
// CHECK-NEXT: <key>extended_message</key>
[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. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; declared without an initial value</string>
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
// CHECK-NEXT: <key>message</key>
[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. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; declared without an initial value</string>
[analyzer] Fix r168019 to work with unpruned paths as well. This is the case where the analyzer tries to print out source locations for code within a synthesized function body, which of course does not have a valid source location. The previous fix attempted to do this during diagnostic path pruning, but some diagnostics have pruning disabled, and so any diagnostic with a path that goes through a synthesized body will either hit an assertion or emit invalid output. <rdar://problem/12657843> (again) llvm-svn: 169631
2012-12-08 03:56:29 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>58</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>2</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Variable &apos;x&apos; is uninitialized when captured by block</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Variable &apos;x&apos; is uninitialized when captured by block</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Variable &apos;x&apos; is uninitialized when captured by block</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>uninitialized variable captured by block</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Look through OpaqueValueExprs when tracking a nil value. This allows us to show /why/ a particular object is nil, even when it is wrapped in an OpaqueValueExpr. llvm-svn: 164445
2012-09-22 09:24:49 +08:00
// CHECK-NEXT: </array>