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/null-deref-path-notes.m

805 lines
35 KiB
Mathematica
Raw Normal View History

[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-store=region -analyzer-output=text -fblocks -verify -Wno-objc-root-class %s
[analyzer] Enable the new edge algorithm by default. ...but don't yet migrate over the existing plist tests. Some of these would be trivial to migrate; others could use a bit of inspection first. In any case, though, the new edge algorithm seems to have proven itself, and we'd like more coverage (and more usage) of it going forwards. llvm-svn: 183165
2013-06-04 07:00:19 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-store=region -analyzer-output=plist-multi-file -analyzer-config path-diagnostics-alternate=false -fblocks -Wno-objc-root-class %s -o %t
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// RUN: FileCheck --input-file=%t %s
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
@interface Root {
@public
int uniqueID;
}
- (id)initWithID:(int)newID;
- (void)refreshID;
@end
int testNull(Root *obj) {
if (obj) return 0;
// expected-note@-1 {{Assuming 'obj' is nil}}
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// expected-note@-2 {{Taking false branch}}
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
[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
int *x = &obj->uniqueID; // expected-note{{'x' initialized to a null pointer value}}
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
return *x; // expected-warning{{Dereference of null pointer (loaded from variable 'x')}} expected-note{{Dereference of null pointer (loaded from variable 'x')}}
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
}
@interface Subclass : Root
@end
@implementation Subclass
- (id)initWithID:(int)newID {
self = [super initWithID:newID]; // expected-note{{Value assigned to 'self'}}
if (self) return self;
// expected-note@-1 {{Assuming 'self' is nil}}
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] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
uniqueID = newID; // expected-warning{{Access to instance variable 'uniqueID' results in a dereference of a null pointer (loaded from variable 'self')}} expected-note{{Access to instance variable 'uniqueID' results in a dereference of a null pointer (loaded from variable 'self')}}
return self;
}
@end
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
void repeatedStores(int coin) {
int *p = 0;
if (coin) {
// expected-note@-1 {{Assuming 'coin' is 0}}
// expected-note@-2 {{Taking false branch}}
extern int *getPointer();
p = getPointer();
} else {
p = 0; // expected-note {{Null pointer value stored to 'p'}}
}
*p = 1; // expected-warning{{Dereference of null pointer}} expected-note{{Dereference of null pointer}}
}
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK: <key>diagnostics</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>9</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>9</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming &apos;obj&apos; is nil</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;obj&apos; is nil</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>14</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>9</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +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>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; initialized to a null pointer value</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
// CHECK-NEXT: <string>&apos;x&apos; initialized to a null pointer value</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +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>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;x&apos;)</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>message</key>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;x&apos;)</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;x&apos;)</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>3ff6dd9f2084f4a0dac8c3688c02fd0f</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testNull</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>6</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Allow ObjC ivar lvalues where the base is nil. By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil. This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept. This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4. llvm-svn: 164960
2012-10-02 03:07:22 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +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>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>28</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>28</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>28</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>33</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>Value assigned to &apos;self&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Value assigned to &apos;self&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>28</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>28</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +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: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming &apos;self&apos; is nil</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;self&apos; is nil</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>29</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>col</key><integer>10</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>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>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>33</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>33</integer>
// CHECK-NEXT: <key>col</key><integer>10</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>33</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>33</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>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Access to instance variable &apos;uniqueID&apos; results in a dereference of a null pointer (loaded from variable &apos;self&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Access to instance variable &apos;uniqueID&apos; results in a dereference of a null pointer (loaded from variable &apos;self&apos;)</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Access to instance variable &apos;uniqueID&apos; results in a dereference of a null pointer (loaded from variable &apos;self&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>208c1267ca2da821fcc1b9183e1d624b</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>Objective-C method</string>
// CHECK-NEXT: <key>issue_context</key><string>initWithID:</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>6</string>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
TrackConstraintBRVisitor and ConditionBRVisitor can emit similar path notes for cases where a value may be assumed to be null, etc. Instead of having redundant diagnostics, do a pass over the generated PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor that are already covered by ConditionBRVisitor, whose notes tend to be better. Fixes <rdar://problem/12252783> llvm-svn: 166728
2012-10-26 06:07:10 +08:00
// CHECK-NEXT: <key>line</key><integer>33</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +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>40</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>40</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>41</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>41</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: </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>41</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>41</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>41</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>41</integer>
// CHECK-NEXT: <key>col</key><integer>10</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>41</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>41</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>41</integer>
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Assuming &apos;coin&apos; is 0</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Assuming &apos;coin&apos; is 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>41</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>41</integer>
// CHECK-NEXT: <key>col</key><integer>10</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>47</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>47</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>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>47</integer>
// CHECK-NEXT: <key>col</key><integer>5</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>47</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>47</integer>
// CHECK-NEXT: <key>col</key><integer>9</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>Null pointer value stored to &apos;p&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Null pointer value stored to &apos;p&apos;</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>47</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>47</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>50</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>50</integer>
// CHECK-NEXT: <key>col</key><integer>3</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>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>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>50</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>50</integer>
// CHECK-NEXT: <key>col</key><integer>3</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>50</integer>
// CHECK-NEXT: <key>col</key><integer>6</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>50</integer>
// CHECK-NEXT: <key>col</key><integer>6</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>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>50</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +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>
// CHECK-NEXT: <key>line</key><integer>50</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>50</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: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>description</key><string>Dereference of null pointer (loaded from variable &apos;p&apos;)</string>
// CHECK-NEXT: <key>category</key><string>Logic error</string>
// CHECK-NEXT: <key>type</key><string>Dereference of null pointer</string>
[Static Analyzer] The name of the checker that reports a bug is added to the plist output. This check_name field does not guaranteed to be the same as the name of the checker in the future. Reviewer: Anna Zaks Differential Revision: http://reviews.llvm.org/D6841 llvm-svn: 228624
2015-02-10 06:52:26 +08:00
// CHECK-NEXT: <key>check_name</key><string>core.NullDereference</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <!-- This hash is experimental and going to change! -->
// CHECK-NEXT: <key>issue_hash_content_of_line_in_context</key><string>9e1f67627fbbfb46b4e3a618246e6b0a</string>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>repeatedStores</string>
[analyzer] Bug identification This patch adds hashes to the plist and html output to be able to identfy bugs for suppressing false positives or diff results against a baseline. This hash aims to be resilient for code evolution and is usable to identify bugs in two different snapshots of the same software. One missing piece however is a permanent unique identifier of the checker that produces the warning. Once that issue is resolved, the hashes generated are going to change. Until that point this feature is marked experimental, but it is suitable for early adoption. Differential Revision: http://reviews.llvm.org/D10305 Original patch by: Bence Babati! llvm-svn: 251011
2015-10-22 19:53:04 +08:00
// CHECK-NEXT: <key>issue_hash_function_offset</key><string>11</string>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>50</integer>
[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse The 2 functions were computing the same location using different logic (each one had edge case bugs that the other one did not). Refactor them to rely on the same logic. The location of the warning reported in text/command line output format will now match that of the plist file. There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and looks better in most cases. llvm-svn: 180165
2013-04-24 07:57:43 +08:00
// CHECK-NEXT: <key>col</key><integer>6</integer>
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </dict>
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue. Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes: PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1; llvm-svn: 164442
2012-09-22 09:24:38 +08:00
// CHECK-NEXT: </array>