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
|
2013-06-04 07:00:19 +08:00
|
|
|
// RUN: %clang --analyze %s -Xanalyzer -analyzer-config -Xanalyzer path-diagnostics-alternate=false -o %t
|
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}}
|
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}}
|
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}}
|
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}}
|
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}}
|
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}}
|
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;
|
|
|
|
}
|
|
|
|
|
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) {
|
|
|
|
// expected-note@-1 {{Left side of '&&' is true}}
|
|
|
|
// expected-note@-2 {{Taking true branch}}
|
|
|
|
*(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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p' is null</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'p' 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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
2013-02-27 03:44:38 +08:00
|
|
|
// CHECK-NEXT: <string>'x' 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>
|
2013-02-27 03:44:38 +08:00
|
|
|
// CHECK-NEXT: <string>'x' 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>
|
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>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>10</integer>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>10</integer>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>10</integer>
|
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>
|
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>
|
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 'x')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'x')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'x')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>10</integer>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p' is null</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'p' 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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p' is null</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'p' 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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p' is null</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'p' 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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
2013-02-27 03:44:38 +08:00
|
|
|
// CHECK-NEXT: <string>'x' 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>
|
2013-02-27 03:44:38 +08:00
|
|
|
// CHECK-NEXT: <string>'x' 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>
|
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>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>44</integer>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>44</integer>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>44</integer>
|
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>
|
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>
|
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 'x')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'x')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'x')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
2012-10-26 06:07:10 +08:00
|
|
|
// CHECK-NEXT: <key>line</key><integer>44</integer>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p' is null</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'p' 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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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>
|
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 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: </dict>
|
|
|
|
// CHECK-NEXT: </array>
|
|
|
|
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable 'p')</string>
|
|
|
|
// CHECK-NEXT: <key>category</key><string>Logic error</string>
|
|
|
|
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
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>
|
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 'a' is not equal to 0</string>
|
|
|
|
// CHECK-NEXT: <key>message</key>
|
|
|
|
// CHECK-NEXT: <string>Assuming 'a' 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>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
2015-10-22 19:53:04 +08:00
|
|
|
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>4</string>
|
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>
|
|
|
|
// CHECK-NEXT: <key>line</key><integer>71</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>71</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>71</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>71</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>71</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>71</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>71</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>71</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>71</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>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
2015-10-22 19:53:04 +08:00
|
|
|
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>4</string>
|
2013-10-26 09:16:26 +08:00
|
|
|
// CHECK-NEXT: <key>location</key>
|
|
|
|
// CHECK-NEXT: <dict>
|
|
|
|
// CHECK-NEXT: <key>line</key><integer>71</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>77</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>77</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>79</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>79</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>79</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>79</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>79</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>79</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>79</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>79</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>79</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>
|
2015-02-10 06:52:26 +08:00
|
|
|
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
|
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>
|
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>
|
2015-10-22 19:53:04 +08:00
|
|
|
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>3</string>
|
2013-10-26 09:16:26 +08:00
|
|
|
// CHECK-NEXT: <key>location</key>
|
|
|
|
// CHECK-NEXT: <dict>
|
|
|
|
// CHECK-NEXT: <key>line</key><integer>79</integer>
|
|
|
|
// 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>
|