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

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

159 lines
5.2 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 -analyzer-checker=core -analyzer-output=text -analyzer-config suppress-null-return-paths=false -verify %s
[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 -analyzer-checker=core -analyzer-output=plist-multi-file -analyzer-config suppress-null-return-paths=false %s -o %t.plist
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.plist | diff -ub %S/Inputs/expected-plists/path-notes.c.plist -
[analyzer] Flatten path diagnostics for text output like we do for HTML. llvm-svn: 161279
2012-08-04 07:08:54 +08:00
void zero(int **p) {
*p = 0;
// expected-note@-1 {{Null pointer value stored to 'a'}}
}
void testZero(int *a) {
zero(&a);
// expected-note@-1 {{Calling 'zero'}}
// expected-note@-2 {{Returning from 'zero'}}
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
[analyzer] When a symbol is null, we should track its constraints. Because of this, we would previously emit NO path notes when a parameter is constrained to null (because there are no stores). Now we show where we made the assumption, which is much more useful. llvm-svn: 161280
2012-08-04 07:09:01 +08:00
}
[analyzer] Simple inline defensive checks suppression Inlining brought a few "null pointer use" false positives, which occur because the callee defensively checks if a pointer is NULL, whereas the caller knows that the pointer cannot be NULL in the context of the given call. This is a first attempt to silence these warnings by tracking the symbolic value along the execution path in the BugReporter. The new visitor finds the node in which the symbol was first constrained to NULL. If the node belongs to a function on the active stack, the warning is reported, otherwise, it is suppressed. There are several areas for follow up work, for example: - How do we differentiate the cases where the first check is followed by another one, which does happen on the active stack? Also, this only silences a fraction of null pointer use warnings. For example, it does not do anything for the cases where NULL was assigned inside a callee. llvm-svn: 176402
2013-03-02 11:20:52 +08:00
void testCheck(int *a) {
if (a) {
// expected-note@-1 + {{Assuming 'a' 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}}
[analyzer] Simple inline defensive checks suppression Inlining brought a few "null pointer use" false positives, which occur because the callee defensively checks if a pointer is NULL, whereas the caller knows that the pointer cannot be NULL in the context of the given call. This is a first attempt to silence these warnings by tracking the symbolic value along the execution path in the BugReporter. The new visitor finds the node in which the symbol was first constrained to NULL. If the node belongs to a function on the active stack, the warning is reported, otherwise, it is suppressed. There are several areas for follow up work, for example: - How do we differentiate the cases where the first check is followed by another one, which does happen on the active stack? Also, this only silences a fraction of null pointer use warnings. For example, it does not do anything for the cases where NULL was assigned inside a callee. llvm-svn: 176402
2013-03-02 11:20:52 +08:00
;
[analyzer] When a symbol is null, we should track its constraints. Because of this, we would previously emit NO path notes when a parameter is constrained to null (because there are no stores). Now we show where we made the assumption, which is much more useful. llvm-svn: 161280
2012-08-04 07:09:01 +08:00
}
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
}
int *getPointer();
void testInitCheck() {
int *a = getPointer();
[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@-1 {{'a' initialized here}}
[analyzer] Simple inline defensive checks suppression Inlining brought a few "null pointer use" false positives, which occur because the callee defensively checks if a pointer is NULL, whereas the caller knows that the pointer cannot be NULL in the context of the given call. This is a first attempt to silence these warnings by tracking the symbolic value along the execution path in the BugReporter. The new visitor finds the node in which the symbol was first constrained to NULL. If the node belongs to a function on the active stack, the warning is reported, otherwise, it is suppressed. There are several areas for follow up work, for example: - How do we differentiate the cases where the first check is followed by another one, which does happen on the active stack? Also, this only silences a fraction of null pointer use warnings. For example, it does not do anything for the cases where NULL was assigned inside a callee. llvm-svn: 176402
2013-03-02 11:20:52 +08:00
if (a) {
// expected-note@-1 + {{Assuming 'a' is null}}
// expected-note@-2 + {{Taking false branch}}
;
}
[analyzer] When a symbol is null, we should track its constraints. Because of this, we would previously emit NO path notes when a parameter is constrained to null (because there are no stores). Now we show where we made the assumption, which is much more useful. llvm-svn: 161280
2012-08-04 07:09:01 +08:00
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
}
void testStoreCheck(int *a) {
a = getPointer();
// expected-note@-1 {{Value assigned to 'a'}}
[analyzer] Simple inline defensive checks suppression Inlining brought a few "null pointer use" false positives, which occur because the callee defensively checks if a pointer is NULL, whereas the caller knows that the pointer cannot be NULL in the context of the given call. This is a first attempt to silence these warnings by tracking the symbolic value along the execution path in the BugReporter. The new visitor finds the node in which the symbol was first constrained to NULL. If the node belongs to a function on the active stack, the warning is reported, otherwise, it is suppressed. There are several areas for follow up work, for example: - How do we differentiate the cases where the first check is followed by another one, which does happen on the active stack? Also, this only silences a fraction of null pointer use warnings. For example, it does not do anything for the cases where NULL was assigned inside a callee. llvm-svn: 176402
2013-03-02 11:20:52 +08:00
if (a) {
// expected-note@-1 + {{Assuming 'a' is null}}
// expected-note@-2 + {{Taking false branch}}
;
}
[analyzer] When a symbol is null, we should track its constraints. Because of this, we would previously emit NO path notes when a parameter is constrained to null (because there are no stores). Now we show where we made the assumption, which is much more useful. llvm-svn: 161280
2012-08-04 07:09:01 +08:00
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
}
[analyzer] Add plist output checks for all four "path notes" tests. No functionality change, but from now on, any new path notes should be tested both with plain-text output (for ease of human auditing) and with plist output (to ensure control flow and events are being correctly represented in Xcode). llvm-svn: 161351
2012-08-07 05:28:14 +08:00
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
int *getZero() {
int *p = 0;
[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@-1 + {{'p' initialized to a null pointer value}}
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
// ^ This note checks that we add a second visitor for the return value.
return p;
[analyzer] Look through casts when trying to track a null pointer dereference. Also, add comments to addTrackNullOrUndefValueVisitor. Thanks for the review, Anna! llvm-svn: 162695
2012-08-28 04:18:30 +08:00
// expected-note@-1 + {{Returning null pointer (loaded from 'p')}}
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
}
void testReturnZero() {
*getZero() = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Calling 'getZero'}}
// expected-note@-2 {{Returning from 'getZero'}}
// expected-note@-3 {{Dereference of null pointer}}
}
[analyzer] Look through casts when trying to track a null pointer dereference. Also, add comments to addTrackNullOrUndefValueVisitor. Thanks for the review, Anna! llvm-svn: 162695
2012-08-28 04:18:30 +08:00
int testReturnZero2() {
return *getZero(); // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Calling 'getZero'}}
// expected-note@-2 {{Returning from 'getZero'}}
// expected-note@-3 {{Dereference of null pointer}}
}
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
void testInitZero() {
int *a = getZero();
[analyzer] If the last store into a region came from a function, step into it. Previously, if we were tracking stores to a variable 'x', and came across this: x = foo(); ...we would simply emit a note here and stop. Now, we'll step into 'foo' and continue tracking the returned value from there. <rdar://problem/12114689> llvm-svn: 162718
2012-08-28 08:50:42 +08:00
// expected-note@-1 {{Calling 'getZero'}}
// expected-note@-2 {{Returning from 'getZero'}}
[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 {{'a' initialized to a null pointer value}}
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
}
void testStoreZero(int *a) {
a = getZero();
[analyzer] If the last store into a region came from a function, step into it. Previously, if we were tracking stores to a variable 'x', and came across this: x = foo(); ...we would simply emit a note here and stop. Now, we'll step into 'foo' and continue tracking the returned value from there. <rdar://problem/12114689> llvm-svn: 162718
2012-08-28 08:50:42 +08:00
// expected-note@-1 {{Calling 'getZero'}}
// expected-note@-2 {{Returning from 'getZero'}}
// expected-note@-3 {{Null pointer value stored to 'a'}}
[analyzer] If we dereference a NULL that came from a function, show the return. More generally, any time we try to track where a null value came from, we should show if it came from a function. This usually isn't necessary if the value is symbolic, but if the value is just a constant we previously just ignored its origin entirely. Now, we'll step into the function and recursively add a visitor to the returned expression. <rdar://problem/12114609> llvm-svn: 162563
2012-08-25 00:34:31 +08:00
*a = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer (loaded from variable 'a')}}
}
[analyzer] Track a null value back through FindLastStoreBRVisitor. Also, tidy up the other tracking visitors so that they mark the right things as interesting and don't do extra work. llvm-svn: 164448
2012-09-22 09:25:00 +08:00
void usePointer(int *p) {
*p = 1; // expected-warning{{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer}}
}
void testUseOfNullPointer() {
// Test the case where an argument expression is itself a call.
usePointer(getZero());
// expected-note@-1 {{Calling 'getZero'}}
// expected-note@-2 {{Returning from 'getZero'}}
// expected-note@-3 {{Passing null pointer value via 1st parameter 'p'}}
// expected-note@-4 {{Calling 'usePointer'}}
}
[analyzer]Print field region even when the base region is not printable llvm-svn: 179395
2013-04-13 02:40:21 +08:00
struct X { char *p; };
void setFieldToNull(struct X *x) {
x->p = 0; // expected-note {{Null pointer value stored to field 'p'}}
}
int testSetFieldToNull(struct X *x) {
setFieldToNull(x); // expected-note {{Calling 'setFieldToNull'}}
// expected-note@-1{{Returning from 'setFieldToNull'}}
return *x->p;
// expected-warning@-1 {{Dereference of null pointer (loaded from field 'p')}}
// expected-note@-2 {{Dereference of null pointer (loaded from field 'p')}}
}
[analyzer] Address code review for r179395 Mostly refactoring + handle the nested fields by printing the innermost field only. llvm-svn: 179572
2013-04-16 06:37:59 +08:00
struct Outer {
struct Inner {
int *p;
} inner;
};
void test(struct Outer *wrapperPtr) {
wrapperPtr->inner.p = 0; // expected-note {{Null pointer value stored to field 'p'}}
*wrapperPtr->inner.p = 1; //expected-warning {{Dereference of null pointer (loaded from field 'p')}}
// expected-note@-1 {{Dereference of null pointer (loaded from field 'p')}}
}
[analyzer] Gain more precision retrieving the right SVal by specifying the type of the expression. Thanks to Jordan for suggesting the fix. llvm-svn: 179732
2013-04-18 06:29:51 +08:00
void test4(int **p) {
if (*p) return; // expected-note {{Taking false branch}}
// expected-note@-1 {{Assuming pointer value is null}}
**p = 1; // expected-warning {{Dereference of null pointer}}
// expected-note@-1 {{Dereference of null pointer}}
}
[analyzer] Fix diagnostics in callees of interesting callees. removeUnneededCalls() is responsible for removing path diagnostic pieces within functions that don't contain "interesting" events. It makes bug reports much tidier. When a stack frame is known to be interesting, the function doesn't descend into it to prune anything within it, even other callees that are totally boring. Fix the function to prune boring callees in interesting stack frames. Differential Revision: https://reviews.llvm.org/D45117 llvm-svn: 329102
2018-04-04 02:52:30 +08:00
void boringCallee() {
}
void interestingCallee(int *x) {
*x = 0; // expected-note{{The value 0 is assigned to 'x'}}
boringCallee(); // no-note
}
int testBoringCalleeOfInterestingCallee() {
int x;
interestingCallee(&x); // expected-note{{Calling 'interestingCallee'}}
// expected-note@-1{{Returning from 'interestingCallee'}}
return 1 / x; // expected-warning{{Division by zero}}
// expected-note@-1{{Division by zero}}
}