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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

87 lines
3.3 KiB
C
Raw Normal View History

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296895
2017-03-04 02:02:02 +08:00
// RUN: %clang_analyze_cc1 %s -analyzer-checker=core.NullDereference -analyzer-output=text -verify
[analyzer] [NFC] Remove unused Extensive diagnostic setting, Rename AlternateExtensive to Extensive. In 2013, five years ago, we have switched to AlternateExtensive diagnostics by default, and Extensive was available under unused, undocumented flag. This change remove the flag, renames the Alternate diagnostic to Extensive (as it's no longer Alternate), and ports the test. Differential Revision: https://reviews.llvm.org/D47670 llvm-svn: 334524
2018-06-13 03:07:41 +08:00
// RUN: %clang_analyze_cc1 %s -analyzer-checker=core.NullDereference -analyzer-output=plist -o %t
Reapply r362994 & co "[analyzer][tests] Add normalize_plist to replace diff_plist" Following r363007, which reverted r362998, r362996, and r362994, reapply with adjustments for the CRLF differences encountered with Windows. Namely, the `-b` option of `diff` is employed, and the `grep` patterns have `$` replaced with `[[:space:]]*$`. llvm-svn: 363069
2019-06-11 22:21:32 +08:00
// RUN: %normalize_plist <%t | diff -ub %S/Inputs/expected-plists/conditional-path-notes.c.plist -
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
void testCondOp(int *p) {
int *x = p ? p : p;
// expected-note@-1 {{Assuming 'p' is null}}
// expected-note@-2 {{'?' condition is false}}
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-3 {{'x' initialized to a null pointer value}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
*x = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'x')}}
}
void testCondProblem(int *p) {
if (p) return;
// expected-note@-1 {{Assuming 'p' is null}}
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// expected-note@-2 {{Taking false branch}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
int x = *p ? 0 : 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'p')}}
(void)x;
}
void testLHSProblem(int *p) {
int x = !p ? *p : 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Assuming 'p' is null}}
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// expected-note@-2 {{'?' condition is true}}
// expected-note@-3 {{Dereference of null pointer (loaded from variable 'p')}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
(void)x;
}
void testRHSProblem(int *p) {
int x = p ? 1 : *p; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Assuming 'p' is null}}
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// expected-note@-2 {{'?' condition is false}}
// expected-note@-3 {{Dereference of null pointer (loaded from variable 'p')}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
(void)x;
}
void testBinaryCondOp(int *p) {
int *x = p ?: p;
// expected-note@-1 {{'?' condition is false}}
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// expected-note@-2 {{'x' initialized to a null pointer value}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
*x = 1; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'x')}}
}
void testBinaryLHSProblem(int *p) {
if (p) return;
// expected-note@-1 {{Assuming 'p' is null}}
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// expected-note@-2 {{Taking false branch}}
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). llvm-svn: 165355
2012-10-06 09:19:36 +08:00
int x = *p ?: 1; // expected-warning{{Dereference of null pointer (loaded from variable 'p')}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'p')}}
(void)x;
}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
void testDiagnosableBranch(int a) {
if (a) {
// expected-note@-1 {{Assuming 'a' is not equal to 0}}
// expected-note@-2 {{Taking true branch}}
Revert "Revert "Temporarily do not drop volatile stores before unreachable"" This reverts commit 52aeacfbf5ce5f949efe0eae029e56db171ea1f7. There isn't full agreement on a path forward yet, but there is agreement that this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338 Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality" This reverts commit f4877c78c0fc98be47b926439bbfe33d5e1d1b6d. And all the related changes to tests: This reverts commit 9a0152799f8e4a59e0483728c9f11c8a7805616f. This reverts commit 3f7c9cc27422f7302cf5a683eeb3978e6cb84270. This reverts commit 329f8197ef59f9bd23328b52d623ba768b51dbb2. This reverts commit aa9f58cc2c48ca6cfc853a2467cd775dc7622746. This reverts commit 2df37d5ddd38091aafbb7d338660e58836f4ac80. This reverts commit a72a44181264fd83e05be958c2712cbd4560aba7.
2021-07-09 23:39:40 +08:00
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// expected-note@-1 {{Dereference of null pointer}}
}
}
[analyzer] Improve "Assuming..." diagnostic pieces for logical operators. Logical short-circuit operators now act like other branch conditions. If the symbolic value of the left-hand side is not known to be true or false (based on the previous execution path), the "Assuming" event piece is added in order to explain that the analyzer is adding a new assumption. Additionally, when the assumption is made against the right-hand side of the logical operator (i.e. when the operator itself acts as a condition in another CFG terminator), the "Assuming..." piece is written out for the right-hand side of the operator rather than for the whole operator. This allows expression-specific diagnostic message text to be constructed. Differential Revision: https://reviews.llvm.org/D25092 llvm-svn: 283302
2016-10-05 16:28:25 +08:00
void testDiagnosableBranchLogical(int a, int b) {
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
if (a && b) {
[analyzer] Improve "Assuming..." diagnostic pieces for logical operators. Logical short-circuit operators now act like other branch conditions. If the symbolic value of the left-hand side is not known to be true or false (based on the previous execution path), the "Assuming" event piece is added in order to explain that the analyzer is adding a new assumption. Additionally, when the assumption is made against the right-hand side of the logical operator (i.e. when the operator itself acts as a condition in another CFG terminator), the "Assuming..." piece is written out for the right-hand side of the operator rather than for the whole operator. This allows expression-specific diagnostic message text to be constructed. Differential Revision: https://reviews.llvm.org/D25092 llvm-svn: 283302
2016-10-05 16:28:25 +08:00
// expected-note@-1 {{Assuming 'a' is not equal to 0}}
[analyzer] Add "Assuming..." diagnostic pieces for unsupported conditions. In the analyzer's path-sensitive reports, when a report goes through a branch and the branch condition cannot be decided to be definitely true or false (based on the previous execution path), an event piece is added that tells the user that a new assumption is added upon the symbolic value of the branch condition. For example, "Assuming 'a' is equal to 3". The text of the assumption is hand-crafted in various manners depending on the AST expression. If the AST expression is too complex and the text of the assumption fails to be constructed, the event piece is omitted. This causes loss of information and misunderstanding of the report. Do not omit the event piece even if the expression is too complex; add a piece with a generic text instead. Differential Revision: https://reviews.llvm.org/D23300 llvm-svn: 283301
2016-10-05 16:19:49 +08:00
// expected-note@-2 {{Left side of '&&' is true}}
[analyzer] Improve "Assuming..." diagnostic pieces for logical operators. Logical short-circuit operators now act like other branch conditions. If the symbolic value of the left-hand side is not known to be true or false (based on the previous execution path), the "Assuming" event piece is added in order to explain that the analyzer is adding a new assumption. Additionally, when the assumption is made against the right-hand side of the logical operator (i.e. when the operator itself acts as a condition in another CFG terminator), the "Assuming..." piece is written out for the right-hand side of the operator rather than for the whole operator. This allows expression-specific diagnostic message text to be constructed. Differential Revision: https://reviews.llvm.org/D25092 llvm-svn: 283302
2016-10-05 16:28:25 +08:00
// expected-note@-3 {{Assuming 'b' is not equal to 0}}
// expected-note@-4 {{Taking true branch}}
Revert "Revert "Temporarily do not drop volatile stores before unreachable"" This reverts commit 52aeacfbf5ce5f949efe0eae029e56db171ea1f7. There isn't full agreement on a path forward yet, but there is agreement that this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338 Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality" This reverts commit f4877c78c0fc98be47b926439bbfe33d5e1d1b6d. And all the related changes to tests: This reverts commit 9a0152799f8e4a59e0483728c9f11c8a7805616f. This reverts commit 3f7c9cc27422f7302cf5a683eeb3978e6cb84270. This reverts commit 329f8197ef59f9bd23328b52d623ba768b51dbb2. This reverts commit aa9f58cc2c48ca6cfc853a2467cd775dc7622746. This reverts commit 2df37d5ddd38091aafbb7d338660e58836f4ac80. This reverts commit a72a44181264fd83e05be958c2712cbd4560aba7.
2021-07-09 23:39:40 +08:00
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// expected-note@-1 {{Dereference of null pointer}}
}
}
void testNonDiagnosableBranchArithmetic(int a, int b) {
if (a - b) {
Revert "[analyzer] Support generating and reasoning over more symbolic constraint types" Assertion `Loc::isLocType(SSE->getLHS()->getType())' failed in Analysis/PR3991.m This reverts commit e469ff2759275e67f9072b3d67fac90f647c0fe6. llvm-svn: 307853
2017-07-13 05:43:42 +08:00
// expected-note@-1 {{Taking true branch}}
[Analyzer] SValBuilder Comparison Rearrangement (with Restrictions and Analyzer Option) Since the range-based constraint manager (default) is weak in handling comparisons where symbols are on both sides it is wise to rearrange them to have symbols only on the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables the constraint manager to store a range m - n .. MAX_VALUE for the symbolic expression A - B. This can be used later to check whether e.g. A + k == B + l can be true, which is also rearranged to A - B == l - k so the constraint manager can check whether l - k is in the range (thus greater than or equal to m - n). The restriction in this version is the the rearrangement happens only if both the symbols and the concrete integers are within the range [min/4 .. max/4] where min and max are the minimal and maximal values of their type. The rearrangement is not enabled by default. It has to be enabled by using -analyzer-config aggressive-relational-comparison-simplification=true. Co-author of this patch is Artem Dergachev (NoQ). Differential Revision: https://reviews.llvm.org/D41938 llvm-svn: 329780
2018-04-11 14:21:12 +08:00
// expected-note@-2 {{Assuming the condition is true}}
Revert "Revert "Temporarily do not drop volatile stores before unreachable"" This reverts commit 52aeacfbf5ce5f949efe0eae029e56db171ea1f7. There isn't full agreement on a path forward yet, but there is agreement that this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338 Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality" This reverts commit f4877c78c0fc98be47b926439bbfe33d5e1d1b6d. And all the related changes to tests: This reverts commit 9a0152799f8e4a59e0483728c9f11c8a7805616f. This reverts commit 3f7c9cc27422f7302cf5a683eeb3978e6cb84270. This reverts commit 329f8197ef59f9bd23328b52d623ba768b51dbb2. This reverts commit aa9f58cc2c48ca6cfc853a2467cd775dc7622746. This reverts commit 2df37d5ddd38091aafbb7d338660e58836f4ac80. This reverts commit a72a44181264fd83e05be958c2712cbd4560aba7.
2021-07-09 23:39:40 +08:00
*(volatile int *)0 = 1; // expected-warning{{Dereference of null pointer}}
[analyzer] Don't emit an "Assuming x is <OP> y" if it's not a comparison op. We could certainly be more precise in many of our diagnostics, but before we were printing "Assuming x is && y", which is just ridiculous. <rdar://problem/15167979> llvm-svn: 193455
2013-10-26 09:16:26 +08:00
// expected-note@-1 {{Dereference of null pointer}}
}
}