2017-03-04 02:02:02 +08:00
|
|
|
// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core,osx.coreFoundation.CFRetainRelease,osx.cocoa.ClassRelease,osx.cocoa.RetainCount -analyzer-store=region -analyzer-output=text -verify %s
|
2018-06-13 03:07:41 +08:00
|
|
|
// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core,osx.coreFoundation.CFRetainRelease,osx.cocoa.ClassRelease,osx.cocoa.RetainCount -analyzer-store=region -analyzer-output=plist-multi-file %s -o %t
|
2018-09-17 18:19:46 +08:00
|
|
|
// RUN: cat %t | %diff_plist %S/Inputs/expected-plists/retain-release-path-notes.m.plist
|
2011-07-16 06:17:54 +08:00
|
|
|
|
|
|
|
/***
|
|
|
|
This file is for testing the path-sensitive notes for retain/release errors.
|
|
|
|
Its goal is to have simple branch coverage of any path-based diagnostics,
|
|
|
|
not to actually check all possible retain/release errors.
|
|
|
|
|
|
|
|
This file includes notes that only appear in a ref-counted analysis.
|
|
|
|
GC-specific notes should go in retain-release-path-notes-gc.m.
|
|
|
|
***/
|
|
|
|
|
|
|
|
@interface NSObject
|
|
|
|
+ (id)alloc;
|
|
|
|
- (id)init;
|
|
|
|
- (void)dealloc;
|
|
|
|
|
|
|
|
- (Class)class;
|
|
|
|
|
|
|
|
- (id)retain;
|
|
|
|
- (void)release;
|
|
|
|
- (void)autorelease;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface Foo : NSObject
|
|
|
|
- (id)methodWithValue;
|
|
|
|
@property(retain) id propertyValue;
|
2012-07-19 05:59:51 +08:00
|
|
|
|
|
|
|
- (id)objectAtIndexedSubscript:(unsigned)index;
|
|
|
|
- (id)objectForKeyedSubscript:(id)key;
|
2011-07-16 06:17:54 +08:00
|
|
|
@end
|
|
|
|
|
|
|
|
typedef struct CFType *CFTypeRef;
|
|
|
|
CFTypeRef CFRetain(CFTypeRef);
|
|
|
|
void CFRelease(CFTypeRef);
|
2013-10-08 01:16:52 +08:00
|
|
|
CFTypeRef CFAutorelease(CFTypeRef __attribute__((cf_consumed)));
|
2011-07-16 06:17:54 +08:00
|
|
|
|
2018-08-18 05:42:59 +08:00
|
|
|
id NSMakeCollectable(CFTypeRef);
|
|
|
|
CFTypeRef CFMakeCollectable(CFTypeRef);
|
|
|
|
|
2011-07-16 06:17:54 +08:00
|
|
|
CFTypeRef CFCreateSomething();
|
|
|
|
CFTypeRef CFGetSomething();
|
|
|
|
|
|
|
|
|
|
|
|
void creationViaAlloc () {
|
2016-12-16 06:55:03 +08:00
|
|
|
id leaked = [[NSObject alloc] init]; // expected-note{{Method returns an instance of NSObject with a +1 retain count}}
|
2013-08-16 09:06:30 +08:00
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void creationViaCFCreate () {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef leaked = CFCreateSomething(); // expected-note{{Call to function 'CFCreateSomething' returns a Core Foundation object of type CFTypeRef with a +1 retain count}}
|
2013-08-16 09:06:30 +08:00
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void acquisitionViaMethod (Foo *foo) {
|
2013-08-16 09:06:30 +08:00
|
|
|
id leaked = [foo methodWithValue]; // expected-note{{Method returns an Objective-C object with a +0 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
[leaked retain]; // expected-note{{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[leaked retain]; // expected-note{{Reference count incremented. The object now has a +2 retain count}}
|
|
|
|
[leaked release]; // expected-note{{Reference count decremented. The object now has a +1 retain count}}
|
2013-08-16 09:06:30 +08:00
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void acquisitionViaProperty (Foo *foo) {
|
2013-08-16 09:06:30 +08:00
|
|
|
id leaked = foo.propertyValue; // expected-note{{Property returns an Objective-C object with a +0 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
[leaked retain]; // expected-note{{Reference count incremented. The object now has a +1 retain count}}
|
2013-08-16 09:06:30 +08:00
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void acquisitionViaCFFunction () {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef leaked = CFGetSomething(); // expected-note{{Call to function 'CFGetSomething' returns a Core Foundation object of type CFTypeRef with a +0 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
CFRetain(leaked); // expected-note{{Reference count incremented. The object now has a +1 retain count}}
|
2013-08-16 09:06:30 +08:00
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void explicitDealloc () {
|
2016-12-16 06:55:03 +08:00
|
|
|
id object = [[NSObject alloc] init]; // expected-note{{Method returns an instance of NSObject with a +1 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
[object dealloc]; // expected-note{{Object released by directly sending the '-dealloc' message}}
|
|
|
|
[object class]; // expected-warning{{Reference-counted object is used after it is released}} // expected-note{{Reference-counted object is used after it is released}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void implicitDealloc () {
|
2016-12-16 06:55:03 +08:00
|
|
|
id object = [[NSObject alloc] init]; // expected-note{{Method returns an instance of NSObject with a +1 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
[object release]; // expected-note{{Object released}}
|
|
|
|
[object class]; // expected-warning{{Reference-counted object is used after it is released}} // expected-note{{Reference-counted object is used after it is released}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void overAutorelease () {
|
2016-12-16 06:55:03 +08:00
|
|
|
id object = [[NSObject alloc] init]; // expected-note{{Method returns an instance of NSObject with a +1 retain count}}
|
2013-04-23 09:42:25 +08:00
|
|
|
[object autorelease]; // expected-note{{Object autoreleased}}
|
|
|
|
[object autorelease]; // expected-note{{Object autoreleased}}
|
|
|
|
return; // expected-warning{{Object autoreleased too many times}} expected-note{{Object was autoreleased 2 times but the object has a +1 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void autoreleaseUnowned (Foo *foo) {
|
|
|
|
id object = foo.propertyValue; // expected-note{{Property returns an Objective-C object with a +0 retain count}}
|
2013-04-23 09:42:25 +08:00
|
|
|
[object autorelease]; // expected-note{{Object autoreleased}}
|
|
|
|
return; // expected-warning{{Object autoreleased too many times}} expected-note{{Object was autoreleased but has a +0 retain count}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
2018-08-18 05:42:59 +08:00
|
|
|
void makeCollectableIgnored() {
|
|
|
|
CFTypeRef leaked = CFCreateSomething(); // expected-note{{Call to function 'CFCreateSomething' returns a Core Foundation object of type CFTypeRef with a +1 retain count}}
|
|
|
|
CFMakeCollectable(leaked);
|
|
|
|
NSMakeCollectable(leaked);
|
|
|
|
return; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'leaked' is not referenced later in this execution path and has a retain count of +1}}
|
|
|
|
}
|
|
|
|
|
2011-07-16 06:17:54 +08:00
|
|
|
CFTypeRef CFCopyRuleViolation () {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef object = CFGetSomething(); // expected-note{{Call to function 'CFGetSomething' returns a Core Foundation object of type CFTypeRef with a +0 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return object; // expected-warning{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}} expected-note{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CFTypeRef CFGetRuleViolation () {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef object = CFCreateSomething(); // expected-note{{Call to function 'CFCreateSomething' returns a Core Foundation object of type CFTypeRef with a +1 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return object; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'object' is returned from a function whose name ('CFGetRuleViolation') does not contain 'Copy' or 'Create'. This violates the naming convention rules given in the Memory Management Guide for Core Foundation}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
@implementation Foo (FundamentalMemoryManagementRules)
|
|
|
|
- (id)copyViolation {
|
|
|
|
id result = self.propertyValue; // expected-note{{Property returns an Objective-C object with a +0 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return result; // expected-warning{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}} expected-note{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
|
|
|
|
2012-07-19 05:59:51 +08:00
|
|
|
- (id)copyViolationIndexedSubscript {
|
|
|
|
id result = self[0]; // expected-note{{Subscript returns an Objective-C object with a +0 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return result; // expected-warning{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}} expected-note{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}}
|
2012-07-19 05:59:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
- (id)copyViolationKeyedSubscript {
|
|
|
|
id result = self[self]; // expected-note{{Subscript returns an Objective-C object with a +0 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return result; // expected-warning{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}} expected-note{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}}
|
2012-07-19 05:59:51 +08:00
|
|
|
}
|
|
|
|
|
2011-07-16 06:17:54 +08:00
|
|
|
- (id)getViolation {
|
2016-12-16 06:55:03 +08:00
|
|
|
id result = [[Foo alloc] init]; // expected-note{{Method returns an instance of Foo with a +1 retain count}}
|
2018-09-22 04:37:20 +08:00
|
|
|
return result; // expected-warning{{leak}} expected-note{{Object leaked: object allocated and stored into 'result' is returned from a method whose name ('getViolation') does not start with 'copy', 'mutableCopy', 'alloc' or 'new'. This violates the naming convention rules given in the Memory Management Guide for Cocoa}}
|
2011-07-16 06:17:54 +08:00
|
|
|
}
|
2012-03-17 13:49:15 +08:00
|
|
|
|
|
|
|
- (id)copyAutorelease {
|
2016-12-16 06:55:03 +08:00
|
|
|
id result = [[Foo alloc] init]; // expected-note{{Method returns an instance of Foo with a +1 retain count}}
|
2013-04-23 09:42:25 +08:00
|
|
|
[result autorelease]; // expected-note{{Object autoreleased}}
|
2012-12-07 02:58:18 +08:00
|
|
|
return result; // expected-warning{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}} expected-note{{Object with a +0 retain count returned to caller where a +1 (owning) retain count is expected}}
|
2012-03-17 13:49:15 +08:00
|
|
|
}
|
2011-07-16 06:17:54 +08:00
|
|
|
@end
|
2012-05-12 13:10:43 +08:00
|
|
|
|
|
|
|
|
|
|
|
typedef unsigned long NSUInteger;
|
|
|
|
|
|
|
|
@interface NSValue : NSObject
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface NSNumber : NSValue
|
|
|
|
+ (NSNumber *)numberWithInt:(int)i;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface NSString : NSObject
|
|
|
|
+ (NSString *)stringWithUTF8String:(const char *)str;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface NSArray : NSObject
|
|
|
|
+ (NSArray *)arrayWithObjects:(const id [])objects count:(NSUInteger)count;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface NSDictionary : NSObject
|
|
|
|
+ (id)dictionaryWithObjects:(const id [])objects forKeys:(const id /* <NSCopying> */ [])keys count:(NSUInteger)count;
|
|
|
|
@end
|
|
|
|
|
|
|
|
|
|
|
|
void testNumericLiteral() {
|
|
|
|
id result = @1; // expected-note{{NSNumber literal is an object with a +0 retain count}}
|
|
|
|
[result release]; // expected-warning{{decrement}} expected-note{{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void testBoxedInt(int x) {
|
|
|
|
id result = @(x); // expected-note{{NSNumber boxed expression produces an object with a +0 retain count}}
|
|
|
|
[result release]; // expected-warning{{decrement}} expected-note{{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void testBoxedString(const char *str) {
|
|
|
|
id result = @(str); // expected-note{{NSString boxed expression produces an object with a +0 retain count}}
|
|
|
|
[result release]; // expected-warning{{decrement}} expected-note{{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void testArray(id obj) {
|
|
|
|
id result = @[obj]; // expected-note{{NSArray literal is an object with a +0 retain count}}
|
|
|
|
[result release]; // expected-warning{{decrement}} expected-note{{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void testDictionary(id key, id value) {
|
|
|
|
id result = @{key: value}; // expected-note{{NSDictionary literal is an object with a +0 retain count}}
|
|
|
|
[result release]; // expected-warning{{decrement}} expected-note{{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
}
|
2012-08-07 05:28:14 +08:00
|
|
|
|
2013-04-11 05:42:06 +08:00
|
|
|
// Test that we step into the init method when the allocated object is leaked due to early escape within init.
|
|
|
|
|
|
|
|
static int Cond;
|
|
|
|
@interface MyObj : NSObject
|
|
|
|
-(id)initX;
|
|
|
|
-(id)initY;
|
|
|
|
-(id)initZ;
|
|
|
|
+(void)test;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation MyObj
|
|
|
|
|
|
|
|
-(id)initX {
|
|
|
|
if (Cond) // expected-note {{Assuming 'Cond' is not equal to 0}}
|
|
|
|
// expected-note@-1{{Taking true branch}}
|
|
|
|
return 0;
|
|
|
|
self = [super init];
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
-(id)initY {
|
2016-12-16 06:55:03 +08:00
|
|
|
self = [super init]; //expected-note {{Method returns an instance of MyObj with a +1 retain count}}
|
2013-04-11 05:42:06 +08:00
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
-(id)initZ {
|
|
|
|
self = [super init];
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
+(void)test {
|
2018-04-06 23:14:32 +08:00
|
|
|
// initX is inlined since we explicitly mark it as interesting
|
2013-04-11 05:42:06 +08:00
|
|
|
id x = [[MyObj alloc] initX]; // expected-warning {{Potential leak of an object}}
|
2016-12-16 06:55:03 +08:00
|
|
|
// expected-note@-1 {{Method returns an instance of MyObj with a +1 retain count}}
|
2013-04-11 05:42:06 +08:00
|
|
|
// expected-note@-2 {{Calling 'initX'}}
|
|
|
|
// expected-note@-3 {{Returning from 'initX'}}
|
|
|
|
// expected-note@-4 {{Object leaked: allocated object is not referenced later in this execution path and has a retain count of +1}}
|
|
|
|
// initI is inlined because the allocation happens within initY
|
2013-08-16 09:06:30 +08:00
|
|
|
id y = [[MyObj alloc] initY];
|
2013-04-11 05:42:06 +08:00
|
|
|
// expected-note@-1 {{Calling 'initY'}}
|
|
|
|
// expected-note@-2 {{Returning from 'initY'}}
|
|
|
|
|
|
|
|
// initZ is not inlined
|
2013-08-16 09:06:30 +08:00
|
|
|
id z = [[MyObj alloc] initZ]; // expected-warning {{Potential leak of an object}}
|
2013-04-11 05:42:06 +08:00
|
|
|
// expected-note@-1 {{Object leaked: allocated object is not referenced later in this execution path and has a retain count of +1}}
|
|
|
|
|
|
|
|
[x release];
|
|
|
|
[z release];
|
|
|
|
}
|
|
|
|
@end
|
2012-08-07 05:28:14 +08:00
|
|
|
|
2013-10-08 01:16:52 +08:00
|
|
|
|
|
|
|
void CFOverAutorelease() {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef object = CFCreateSomething(); // expected-note{{Call to function 'CFCreateSomething' returns a Core Foundation object of type CFTypeRef with a +1 retain count}}
|
2013-10-08 01:16:52 +08:00
|
|
|
CFAutorelease(object); // expected-note{{Object autoreleased}}
|
|
|
|
CFAutorelease(object); // expected-note{{Object autoreleased}}
|
|
|
|
return; // expected-warning{{Object autoreleased too many times}} expected-note{{Object was autoreleased 2 times but the object has a +1 retain count}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CFAutoreleaseUnowned() {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef object = CFGetSomething(); // expected-note{{Call to function 'CFGetSomething' returns a Core Foundation object of type CFTypeRef with a +0 retain count}}
|
2013-10-08 01:16:52 +08:00
|
|
|
CFAutorelease(object); // expected-note{{Object autoreleased}}
|
|
|
|
return; // expected-warning{{Object autoreleased too many times}} expected-note{{Object was autoreleased but has a +0 retain count}}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CFAutoreleaseUnownedMixed() {
|
2016-12-16 06:55:03 +08:00
|
|
|
CFTypeRef object = CFGetSomething(); // expected-note{{Call to function 'CFGetSomething' returns a Core Foundation object of type CFTypeRef with a +0 retain count}}
|
2013-10-08 01:16:52 +08:00
|
|
|
CFAutorelease(object); // expected-note{{Object autoreleased}}
|
|
|
|
[(id)object autorelease]; // expected-note{{Object autoreleased}}
|
|
|
|
return; // expected-warning{{Object autoreleased too many times}} expected-note{{Object was autoreleased 2 times but the object has a +0 retain count}}
|
|
|
|
}
|
|
|
|
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
@interface PropertiesAndIvars : NSObject
|
|
|
|
@property (strong) id ownedProp;
|
|
|
|
@property (unsafe_unretained) id unownedProp;
|
|
|
|
@property (nonatomic, strong) id manualProp;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface NSObject (PropertiesAndIvarsHelper)
|
|
|
|
- (void)myMethod;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation PropertiesAndIvars {
|
|
|
|
id _ivarOnly;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (id)manualProp {
|
|
|
|
return _manualProp;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)testOverreleaseUnownedIvar {
|
2015-03-31 04:17:47 +08:00
|
|
|
[_unownedProp retain]; // FIXME-note {{Object loaded from instance variable}}
|
|
|
|
// FIXME-note@-1 {{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[_unownedProp release]; // FIXME-note {{Reference count decremented}}
|
|
|
|
[_unownedProp release]; // FIXME-note {{Incorrect decrement of the reference count of an object that is not owned at this point by the caller}}
|
|
|
|
// FIXME-warning@-1 {{not owned at this point by the caller}}
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)testOverreleaseOwnedIvarUse {
|
2015-03-31 04:18:00 +08:00
|
|
|
[_ownedProp retain]; // FIXME-note {{Object loaded from instance variable}}
|
|
|
|
// FIXME-note@-1 {{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[_ownedProp release]; // FIXME-note {{Reference count decremented}}
|
|
|
|
[_ownedProp release]; // FIXME-note {{Strong instance variable relinquished. Object released}}
|
|
|
|
[_ownedProp myMethod]; // FIXME-note {{Reference-counted object is used after it is released}}
|
|
|
|
// FIXME-warning@-1 {{used after it is released}}
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)testOverreleaseIvarOnlyUse {
|
2015-03-31 04:18:00 +08:00
|
|
|
[_ivarOnly retain]; // FIXME-note {{Object loaded from instance variable}}
|
|
|
|
// FIXME-note@-1 {{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[_ivarOnly release]; // FIXME-note {{Reference count decremented}}
|
|
|
|
[_ivarOnly release]; // FIXME-note {{Strong instance variable relinquished. Object released}}
|
|
|
|
[_ivarOnly myMethod]; // FIXME-note {{Reference-counted object is used after it is released}}
|
|
|
|
// FIXME-warning@-1 {{used after it is released}}
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)testOverreleaseOwnedIvarAutorelease {
|
2015-03-31 04:18:00 +08:00
|
|
|
[_ownedProp retain]; // FIXME-note {{Object loaded from instance variable}}
|
|
|
|
// FIXME-note@-1 {{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[_ownedProp release]; // FIXME-note {{Reference count decremented}}
|
|
|
|
[_ownedProp autorelease]; // FIXME-note {{Object autoreleased}}
|
|
|
|
[_ownedProp autorelease]; // FIXME-note {{Object autoreleased}}
|
|
|
|
// FIXME-note@+1 {{Object was autoreleased 2 times but the object has a +0 retain count}}
|
|
|
|
} // FIXME-warning{{Object autoreleased too many times}}
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
|
|
|
|
- (void)testOverreleaseIvarOnlyAutorelease {
|
2015-03-31 04:18:00 +08:00
|
|
|
[_ivarOnly retain]; // FIXME-note {{Object loaded from instance variable}}
|
|
|
|
// FIXME-note@-1 {{Reference count incremented. The object now has a +1 retain count}}
|
|
|
|
[_ivarOnly release]; // FIXME-note {{Reference count decremented}}
|
|
|
|
[_ivarOnly autorelease]; // FIXME-note {{Object autoreleased}}
|
|
|
|
[_ivarOnly autorelease]; // FIXME-note {{Object autoreleased}}
|
|
|
|
// FIXME-note@+1 {{Object was autoreleased 2 times but the object has a +0 retain count}}
|
|
|
|
} // FIXME-warning{{Object autoreleased too many times}}
|
[analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
2015-02-05 03:24:52 +08:00
|
|
|
|
|
|
|
@end
|
|
|
|
|
|
|
|
|
2013-10-08 01:16:52 +08:00
|
|
|
|