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/inline-plist.c

1985 lines
88 KiB
C
Raw Normal View History

[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
// RUN: %clang --analyze %s -fblocks -Xanalyzer -analyzer-output=text -Xanalyzer -analyzer-config -Xanalyzer suppress-null-return-paths=false -Xclang -verify %s
[analyzer] Enable the new edge algorithm by default. ...but don't yet migrate over the existing plist tests. Some of these would be trivial to migrate; others could use a bit of inspection first. In any case, though, the new edge algorithm seems to have proven itself, and we'd like more coverage (and more usage) of it going forwards. llvm-svn: 183165
2013-06-04 07:00:19 +08:00
// RUN: %clang --analyze %s -fblocks -Xanalyzer -analyzer-config -Xanalyzer suppress-null-return-paths=false -Xanalyzer -analyzer-config -Xanalyzer path-diagnostics-alternate=false -o %t
[analyzer diagnostics] flush locations *before* popping the current path when visiting a CallEnter. Fixes <rdar://problem/10967815> llvm-svn: 151938
2012-03-03 05:16:22 +08:00
// RUN: FileCheck -input-file %t %s
// <rdar://problem/10967815>
void mmm(int y) {
if (y != 0)
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
y++;
[analyzer diagnostics] flush locations *before* popping the current path when visiting a CallEnter. Fixes <rdar://problem/10967815> llvm-svn: 151938
2012-03-03 05:16:22 +08:00
}
int foo(int x, int y) {
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
mmm(y);
if (x != 0) {
// expected-note@-1 {{Assuming 'x' is equal to 0}}
// expected-note@-2 {{Taking false branch}}
x++;
}
return 5/x; // expected-warning{{Division by zero}} expected-note{{Division by zero}}
[analyzer diagnostics] flush locations *before* popping the current path when visiting a CallEnter. Fixes <rdar://problem/10967815> llvm-svn: 151938
2012-03-03 05:16:22 +08:00
}
[analyzer] Include inlining call stack depth in plist output. llvm-svn: 152584
2012-03-13 06:10:57 +08:00
// Test a bug triggering only when inlined.
void has_bug(int *p) {
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
*p = 0xDEADBEEF; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
[analyzer] Include inlining call stack depth in plist output. llvm-svn: 152584
2012-03-13 06:10:57 +08:00
}
void test_has_bug() {
has_bug(0);
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// expected-note@-1 {{Passing null pointer value via 1st parameter 'p'}}
// expected-note@-2 {{Calling 'has_bug'}}
[analyzer] Include inlining call stack depth in plist output. llvm-svn: 152584
2012-03-13 06:10:57 +08:00
}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
void triggers_bug(int *p) {
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
*p = 0xDEADBEEF; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
}
// This function triggers a bug by calling triggers_bug(). The diagnostics
// should show when p is assumed to be null.
void bar(int *p) {
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
if (!!p) {
// expected-note@-1 {{Assuming 'p' is null}}
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// expected-note@-2 {{Taking false branch}}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
return;
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
if (p == 0) {
// expected-note@-1 {{Taking true branch}}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
triggers_bug(p);
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// expected-note@-1 {{Passing null pointer value via 1st parameter 'p'}}
// expected-note@-2 {{Calling 'triggers_bug'}}
}
Refine analyzer diagnostics by adding an expression "cone-of-influence" to reverse track interesting values through interesting expressions. This allows us to map from interesting values in a caller to interesting values in a caller, thus recovering some precision in diagnostics lost from IPA. Fixes <rdar://problem/11327497> llvm-svn: 155971
2012-05-02 08:31:29 +08:00
}
Rework ExprEngine::evalLoad and clients (e.g. VisitBinaryOperator) so that when we generate a new ExplodedNode we use the same Expr* as the one being currently visited. This is preparation for transitioning to having ProgramPoints refer to CFGStmts. This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact, as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but it will look a lot cleaner when were start using CFGStmt* in the appropriate places. As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed. I have audited these, and they look reasonable. llvm-svn: 154214
2012-04-07 06:10:18 +08:00
static analyzer: add inlining support for directly called blocks. llvm-svn: 157833
2012-06-02 04:04:04 +08:00
// ========================================================================== //
// Test inlining of blocks.
// ========================================================================== //
void test_block__capture_null() {
[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
int *p = 0; // expected-note{{'p' initialized to a null pointer value}}
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
^(){ // expected-note {{Calling anonymous block}}
*p = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
}();
static analyzer: add inlining support for directly called blocks. llvm-svn: 157833
2012-06-02 04:04:04 +08:00
}
void test_block_ret() {
[analyzer] Suppress paths involving a reference whose rvalue is null. Most map types have an operator[] that inserts a new element if the key isn't found, then returns a reference to the value slot so that you can assign into it. However, if the value type is a pointer, it will be initialized to null. This is usually no problem. However, if the user /knows/ the map contains a value for a particular key, they may just use it immediately: // From ClangSACheckersEmitter.cpp recordGroupMap[group]->Checkers In this case the analyzer reports a null dereference on the path where the key is not in the map, even though the user knows that path is impossible here. They could silence the warning by adding an assertion, but that means splitting up the expression and introducing a local variable. (Note that the analyzer has no way of knowing that recordGroupMap[group] will return the same reference if called twice in a row!) We already have logic that says a null dereference has a high chance of being a false positive if the null came from an inlined function. This patch simply extends that to references whose rvalues are null as well, silencing several false positives in LLVM. <rdar://problem/13239854> llvm-svn: 176371
2013-03-02 03:45:10 +08:00
int *p = ^int*(){ // expected-note {{Calling anonymous block}} expected-note{{Returning to caller}} expected-note {{'p' initialized to a null pointer value}}
[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
int *q = 0; // expected-note {{'q' initialized to a null pointer value}}
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
return q; // expected-note {{Returning null pointer (loaded from 'q')}}
}();
*p = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
static analyzer: add inlining support for directly called blocks. llvm-svn: 157833
2012-06-02 04:04:04 +08:00
}
void test_block_blockvar() {
__block int *p;
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
^(){ // expected-note{{Calling anonymous block}} expected-note{{Returning to caller}}
p = 0; // expected-note{{Null pointer value stored to 'p'}}
}();
*p = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
static analyzer: add inlining support for directly called blocks. llvm-svn: 157833
2012-06-02 04:04:04 +08:00
}
void test_block_arg() {
int *p;
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
^(int **q){ // expected-note{{Calling anonymous block}} expected-note{{Returning to caller}}
*q = 0; // expected-note{{Null pointer value stored to 'p'}}
}(&p);
*p = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}} expected-note{{Dereference of null pointer (loaded from variable 'p')}}
static analyzer: add inlining support for directly called blocks. llvm-svn: 157833
2012-06-02 04:04:04 +08:00
}
[analyzer diagnostics] flush locations *before* popping the current path when visiting a CallEnter. Fixes <rdar://problem/10967815> llvm-svn: 151938
2012-03-03 05:16:22 +08:00
// CHECK: <key>diagnostics</key>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>12</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>12</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Assuming &apos;x&apos; is equal to 0</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Assuming &apos;x&apos; is equal to 0</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>8</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Division by zero</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.DivideZero</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>8bca94f2f862468bb877fb70e66a3304</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>foo</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>7</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// 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>27</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>27</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: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>27</integer>
// CHECK-NEXT: <key>col</key><integer>11</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>27</integer>
// CHECK-NEXT: <key>col</key><integer>11</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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
// CHECK-NEXT: <key>col</key><integer>11</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Passing null pointer value via 1st parameter &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Passing null pointer value via 1st parameter &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>27</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling &apos;has_bug&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling &apos;has_bug&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>22</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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;test_has_bug&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;test_has_bug&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>22</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>22</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// 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>23</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>23</integer>
// 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>
// CHECK-NEXT: <key>line</key><integer>23</integer>
// CHECK-NEXT: <key>col</key><integer>6</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>23</integer>
// CHECK-NEXT: <key>col</key><integer>6</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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>62ddaf4e66ff527b230b474b98791ced</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>has_bug</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>1</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>23</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>8</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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>39</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>45</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>45</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>45</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>45</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>16</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>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>16</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +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: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Passing null pointer value via 1st parameter &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Passing null pointer value via 1st parameter &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>47</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>19</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;triggers_bug&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling &apos;triggers_bug&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>32</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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;bar&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;bar&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>32</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>32</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// 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>33</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>33</integer>
// 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>
// CHECK-NEXT: <key>line</key><integer>33</integer>
// CHECK-NEXT: <key>col</key><integer>6</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>33</integer>
// CHECK-NEXT: <key>col</key><integer>6</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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>1ee3fb0b2fbd9c66e0cc34ca1181ece3</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>triggers_bug</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>1</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>58</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>58</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>58</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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: </array>
// CHECK-NEXT: <key>depth</key><integer>0</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;p&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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;p&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>58</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>58</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>61</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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 anonymous block</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling anonymous block</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</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;test_block__capture_null&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;test_block__capture_null&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>59</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// 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>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: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>60</integer>
// CHECK-NEXT: <key>col</key><integer>8</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>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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>a2e7504f29818834127c44ba841f4da8</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>60</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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: </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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>69</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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 anonymous block</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling anonymous block</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</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;test_block_ret&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;test_block_ret&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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] 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;q&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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;q&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>67</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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 (loaded from &apos;q&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Returning null pointer (loaded from &apos;q&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>69</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning to caller</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Returning to caller</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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: </array>
// CHECK-NEXT: <key>depth</key><integer>0</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;p&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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;p&apos; initialized to a null pointer value</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>66</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>931be9c3a45b61c0a9c99b4772bd6fca</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>test_block_ret</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>5</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>70</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>74</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>74</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>9</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>77</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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 anonymous block</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling anonymous block</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</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;test_block_blockvar&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;test_block_blockvar&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>76</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>76</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>76</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>76</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>76</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>9</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Null pointer value stored to &apos;p&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Null pointer value stored to &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>77</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning to caller</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Returning to caller</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>75</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>524a8647c40f017409d858ff70900c1a</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>test_block_blockvar</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>5</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>82</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>82</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>5</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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>85</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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 anonymous block</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Calling anonymous block</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</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;test_block_arg&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Entered call from &apos;test_block_arg&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>84</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>84</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>84</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>84</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>84</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Null pointer value stored to &apos;p&apos;</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Null pointer value stored to &apos;p&apos;</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>85</integer>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning to caller</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Returning to caller</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>83</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// 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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
[analyzer] Better path notes for null pointers passed as arguments. Rather than saying "Null pointer value stored to 'foo'", we now say "Passing null pointer value via Nth parameter 'foo'", which is much better. The note is also now on the argument expression as well, rather than the entire call. This paves the way for continuing to track arguments back to their sources. <rdar://problem/12211490> llvm-svn: 164444
2012-09-22 09:24:46 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>0efdf891fbddf2932f9d434968b94164</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>test_block_arg</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>5</string>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>86</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
Attempt (again) to stabilize the order of the emission of diagnostics of the analyzer by using the FullProfile() of a PathDiagnostic for ordering them. llvm-svn: 163455
2012-09-08 12:26:37 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>