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/conditional-path-notes.c

1674 lines
74 KiB
C
Raw Normal View History

ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// RUN: %clang --analyze %s -Xanalyzer -analyzer-output=text -Xclang -verify
[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 -Xanalyzer -analyzer-config -Xanalyzer path-diagnostics-alternate=false -o %t
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
// RUN: FileCheck --input-file=%t %s
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
void testCondOp(int *p) {
int *x = p ? p : p;
// expected-note@-1 {{Assuming 'p' is null}}
// expected-note@-2 {{'?' condition is false}}
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-3 {{'x' initialized to a null pointer value}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
*x = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'x')}}
}
void testCondProblem(int *p) {
if (p) return;
// 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}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
int x = *p ? 0 : 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'p')}}
(void)x;
}
void testLHSProblem(int *p) {
int x = !p ? *p : 1; // expected-warning{{Dereference of null pointer (loaded from variable '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 {{'?' condition is true}}
// expected-note@-3 {{Dereference of null pointer (loaded from variable 'p')}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
(void)x;
}
void testRHSProblem(int *p) {
int x = p ? 1 : *p; // expected-warning{{Dereference of null pointer (loaded from variable '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 {{'?' condition is false}}
// expected-note@-3 {{Dereference of null pointer (loaded from variable 'p')}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
(void)x;
}
void testBinaryCondOp(int *p) {
int *x = p ?: p;
// expected-note@-1 {{'?' condition is false}}
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-2 {{'x' initialized to a null pointer value}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
*x = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'x')}}
}
void testBinaryLHSProblem(int *p) {
if (p) return;
// 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}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
int x = *p ?: 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'p')}}
(void)x;
}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
void testDiagnosableBranch(int a) {
if (a) {
// expected-note@-1 {{Assuming 'a' is not equal to 0}}
// expected-note@-2 {{Taking true branch}}
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer}}
}
}
void testNonDiagnosableBranchLogical(int a, int b) {
if (a && b) {
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// expected-note@-1 {{Assuming the condition is true}}
// expected-note@-2 {{Left side of '&&' is true}}
// expected-note@-3 {{Taking true branch}}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer}}
}
}
void testNonDiagnosableBranchArithmetic(int a, int b) {
if (a - b) {
// expected-note@-1 {{Taking true branch}}
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer}}
}
}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK: <key>diagnostics</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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;x&apos; initialized to a null pointer value</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; initialized to a null pointer value</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>6</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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;x&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;x&apos;)</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;x&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>8ea3f4e6a3100c73f078fac15acb0a9c</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testCondOp</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>10</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>15</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// 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>
// 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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// 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>2c219a33e961fc1be7d54b700867259e</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testCondProblem</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>19</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
// 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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// 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>
// 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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>16</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>
// 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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>16</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// 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>8d43b511137326eab7d1242950e72984</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testLHSProblem</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>25</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>16</integer>
// 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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// 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>
// 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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>19</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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: </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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>19</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>20</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>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// 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>b8e93b7355a6779a960f9a942fafac15</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testRHSProblem</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>33</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>19</integer>
// 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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>17</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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;x&apos; initialized to a null pointer value</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; initialized to a null pointer value</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>41</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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;x&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;x&apos;)</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;x&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>a944281d096940ca43ec995649b48b5f</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testBinaryCondOp</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>4</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>44</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>
// CHECK-NEXT: <string>Assuming &apos;p&apos; is null</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</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>49</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// 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>
// 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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// 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>4db164bbf5cea42d75c5e838be1eef6f</string>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testBinaryLHSProblem</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>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +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>53</integer>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</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>59</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming &apos;a&apos; is not equal to 0</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;a&apos; is not equal to 0</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>59</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</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>62</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>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>62</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>62</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>62</integer>
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</integer>
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</integer>
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</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>62</integer>
// CHECK-NEXT: <key>col</key><integer>26</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[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>778d56ad485369222613ac2c03b97700</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testDiagnosableBranch</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>4</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>62</integer>
// CHECK-NEXT: <key>col</key><integer>24</integer>
// 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>
// CHECK-NEXT: <key>line</key><integer>68</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>68</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>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>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming the condition is true</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming the condition is true</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>68</integer>
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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>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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>26</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[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>ebd0bb32bbdcaa2a806ff1984974c07a</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testNonDiagnosableBranchLogical</string>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>5</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>72</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</integer>
// 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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>78</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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>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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +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>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</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] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>26</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[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>f56671e5f67c73abef619b56f7c29fa4</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testNonDiagnosableBranchArithmetic</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>3</string>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// CHECK-NEXT: <key>line</key><integer>80</integer>
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// CHECK-NEXT: <key>col</key><integer>24</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
// CHECK-NEXT: </array>