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

187 lines
6.7 KiB
C
Raw Normal View History

[analyzer] -analyzer-ipa=inlining is now the default. Remove it from tests. The actual change here is a little more complicated than the summary above. What we want to do is have our generic inlining tests run under whatever mode is the default. However, there are some tests that depend on the presence of C++ inlining, which still has some rough edges. These tests have been explicitly marked as -analyzer-ipa=inlining in preparation for a new mode that limits inlining to C functions and blocks. This will be the default until the false positives for C++ have been brought down to manageable levels. llvm-svn: 162317
2012-08-22 05:44:07 +08:00
// RUN: %clang --analyze %s -o %t > /dev/null 2>&1
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// RUN: FileCheck -input-file %t %s
static inline bug(int *p) {
*p = 0xDEADBEEF;
}
void test_bug_1() {
int *p = 0;
bug(p);
}
void test_bug_2() {
int *p = 0;
bug(p);
}
// CHECK: <?xml version="1.0" encoding="UTF-8"?>
// CHECK: <plist version="1.0">
// CHECK: <dict>
// CHECK: <key>files</key>
// CHECK: <array>
// CHECK: </array>
// CHECK: <key>diagnostics</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>path</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>kind</key><string>control</string>
// CHECK: <key>edges</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>start</key>
// CHECK: <array>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>14</integer>
Make PathDiagnosticBuilder sensitive to varying LocationContexts, thus fixing a bug in the inlining diagnostics where the wrong location could be used. llvm-svn: 151349
2012-02-24 15:12:52 +08:00
// CHECK: <key>col</key><integer>3</integer>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>14</integer>
PlistDiagnostics: force the ranges for control-flow edges to be single locations, forcing adjacent edges to have compatible ranges. This simplifies the layout logic for some clients. llvm-svn: 158028
2012-06-06 06:00:52 +08:00
// CHECK: <key>col</key><integer>5</integer>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: <key>end</key>
// CHECK: <array>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>15</integer>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>15</integer>
PlistDiagnostics: force the ranges for control-flow edges to be single locations, forcing adjacent edges to have compatible ranges. This simplifies the layout logic for some clients. llvm-svn: 158028
2012-06-06 06:00:52 +08:00
// CHECK: <key>col</key><integer>5</integer>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>kind</key><string>event</string>
// CHECK: <key>location</key>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>15</integer>
Update test case. llvm-svn: 149964
2012-02-07 11:56:27 +08:00
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
Reapply r151317, but when computing the PathDiagnostic profile and size keep into account the nested structure. Also fix a problem with how inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information. llvm-svn: 151346
2012-02-24 14:00:00 +08:00
// CHECK: <key>ranges</key>
// CHECK: <array>
// CHECK: <array>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>15</integer>
Reapply r151317, but when computing the PathDiagnostic profile and size keep into account the nested structure. Also fix a problem with how inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information. llvm-svn: 151346
2012-02-24 14:00:00 +08:00
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <key>line</key><integer>15</integer>
Reapply r151317, but when computing the PathDiagnostic profile and size keep into account the nested structure. Also fix a problem with how inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information. llvm-svn: 151346
2012-02-24 14:00:00 +08:00
// CHECK: <key>col</key><integer>8</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </array>
Include full plist output in FileCheck test. llvm-svn: 152859
2012-03-16 06:14:09 +08:00
// CHECK: <key>depth</key><integer>0</integer>
Update test case. llvm-svn: 149964
2012-02-07 11:56:27 +08:00
// CHECK: <key>extended_message</key>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <string>Calling &apos;bug&apos;</string>
Update test case. llvm-svn: 149964
2012-02-07 11:56:27 +08:00
// CHECK: <key>message</key>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <string>Calling &apos;bug&apos;</string>
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>kind</key><string>event</string>
// CHECK: <key>location</key>
// CHECK: <dict>
// CHECK: <key>line</key><integer>4</integer>
// CHECK: <key>col</key><integer>1</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
Include full plist output in FileCheck test. llvm-svn: 152859
2012-03-16 06:14:09 +08:00
// CHECK: <key>depth</key><integer>1</integer>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <key>extended_message</key>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <string>Entered call from &apos;test_bug_2&apos;</string>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <key>message</key>
[analyzer] Solve another source of non-determinism in the diagnostic engine. The code that was supposed to split the tie in a deterministic way is not deterministic. Most likely one of the profile methods uses a pointer. After this change we do finally get the consistent diagnostic output. Testing this requires running the analyzer on large code bases and diffing the results. llvm-svn: 161224
2012-08-03 07:41:05 +08:00
// CHECK: <string>Entered call from &apos;test_bug_2&apos;</string>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>kind</key><string>control</string>
// CHECK: <key>edges</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>start</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>line</key><integer>4</integer>
// CHECK: <key>col</key><integer>1</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>line</key><integer>4</integer>
PlistDiagnostics: force the ranges for control-flow edges to be single locations, forcing adjacent edges to have compatible ranges. This simplifies the layout logic for some clients. llvm-svn: 158028
2012-06-06 06:00:52 +08:00
// CHECK: <key>col</key><integer>6</integer>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: <key>end</key>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>line</key><integer>5</integer>
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>line</key><integer>5</integer>
Rework ExprEngine::evalLoad and clients (e.g. VisitBinaryOperator) so that when we generate a new ExplodedNode we use the same Expr* as the one being currently visited. This is preparation for transitioning to having ProgramPoints refer to CFGStmts. This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact, as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but it will look a lot cleaner when were start using CFGStmt* in the appropriate places. As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed. I have audited these, and they look reasonable. llvm-svn: 154214
2012-04-07 06:10:18 +08:00
// CHECK: <key>col</key><integer>3</integer>
[analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge. llvm-svn: 152086
2012-03-06 09:25:01 +08:00
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </dict>
// CHECK: </array>
Update test case. llvm-svn: 149964
2012-02-07 11:56:27 +08:00
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>kind</key><string>event</string>
// CHECK: <key>location</key>
// CHECK: <dict>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>line</key><integer>5</integer>
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <key>ranges</key>
// CHECK: <array>
// CHECK: <array>
// CHECK: <dict>
// CHECK: <key>line</key><integer>5</integer>
// CHECK: <key>col</key><integer>4</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: <dict>
// CHECK: <key>line</key><integer>5</integer>
// CHECK: <key>col</key><integer>4</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </array>
Include full plist output in FileCheck test. llvm-svn: 152859
2012-03-16 06:14:09 +08:00
// CHECK: <key>depth</key><integer>1</integer>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>extended_message</key>
// CHECK: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK: <key>message</key>
// CHECK: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK: </dict>
// CHECK: </array>
// CHECK: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK: <key>category</key><string>Logic error</string>
// CHECK: <key>type</key><string>Dereference of null pointer</string>
Rework ExprEngine::evalLoad and clients (e.g. VisitBinaryOperator) so that when we generate a new ExplodedNode we use the same Expr* as the one being currently visited. This is preparation for transitioning to having ProgramPoints refer to CFGStmts. This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact, as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but it will look a lot cleaner when were start using CFGStmt* in the appropriate places. As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed. I have audited these, and they look reasonable. llvm-svn: 154214
2012-04-07 06:10:18 +08:00
// CHECK: <key>issue_context_kind</key><string>function</string>
// CHECK: <key>issue_context</key><string>bug</string>
[analyzer] Plist: change the type of issue_hash from int to string. This gives more flexibility to what could be stored as issue_hash. llvm-svn: 171824
2013-01-08 08:25:22 +08:00
// CHECK: <key>issue_hash</key><string>1</string>
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which shows up with inlining). llvm-svn: 148997
2012-01-26 07:47:14 +08:00
// CHECK: <key>location</key>
// CHECK: <dict>
// CHECK: <key>line</key><integer>5</integer>
// CHECK: <key>col</key><integer>3</integer>
// CHECK: <key>file</key><integer>0</integer>
// CHECK: </dict>
// CHECK: </dict>
// CHECK: </array>
// CHECK: </dict>
// CHECK: </plist>
PlistDiagnostics: force the ranges for control-flow edges to be single locations, forcing adjacent edges to have compatible ranges. This simplifies the layout logic for some clients. llvm-svn: 158028
2012-06-06 06:00:52 +08:00