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

489 lines
21 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
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: %clang_cc1 -analyze -analyzer-checker=core -analyzer-store=region -analyzer-output=plist-multi-file -fblocks -Wno-objc-root-class %s -o %t
// 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] 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
int *x = &obj->uniqueID; // expected-note{{Variable 'x' initialized to a null pointer value}}
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
// 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] 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>Variable &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] 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>Variable &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>
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>testNull</string>
[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>issue_hash</key><integer>6</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>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>
// 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] 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>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] 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>18</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>
// 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>
// CHECK-NEXT: <key>issue_context_kind</key><string>Objective-C method</string>
// CHECK-NEXT: <key>issue_context</key><string>initWithID:</string>
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>issue_hash</key><integer>6</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>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] 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>
// CHECK-NEXT: </array>