2012-04-07 02:12:22 +08:00
|
|
|
// RUN: %clang_cc1 -triple i386-apple-darwin9 -fsyntax-only -verify -Wno-objc-root-class %s
|
2009-04-08 05:25:06 +08:00
|
|
|
|
|
|
|
@interface Subtask
|
|
|
|
{
|
|
|
|
id _delegate;
|
|
|
|
}
|
2015-10-27 12:54:50 +08:00
|
|
|
@property(nonatomic,readwrite,assign) id __weak delegate; // expected-error {{unsafe_unretained property 'delegate' may not also be declared __weak}}
|
2009-04-08 05:25:06 +08:00
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation Subtask
|
|
|
|
@synthesize delegate = _delegate;
|
|
|
|
@end
|
|
|
|
|
|
|
|
|
2009-04-11 06:42:54 +08:00
|
|
|
@interface PVSelectionOverlayView2
|
|
|
|
{
|
2015-10-27 12:54:50 +08:00
|
|
|
id __weak _selectionRect; // expected-error {{cannot create __weak reference because the current deployment target does not support weak references}} expected-error {{existing instance variable '_selectionRect' for property 'selectionRect' with assign attribute must be __unsafe_unretained}}
|
2009-04-11 06:42:54 +08:00
|
|
|
}
|
|
|
|
|
Define weak and __weak to mean ARC-style weak references, even in MRC.
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
2015-10-23 02:38:17 +08:00
|
|
|
@property(assign) id selectionRect; // expected-note {{property declared here}}
|
2009-04-11 06:42:54 +08:00
|
|
|
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation PVSelectionOverlayView2
|
|
|
|
|
Define weak and __weak to mean ARC-style weak references, even in MRC.
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
2015-10-23 02:38:17 +08:00
|
|
|
@synthesize selectionRect = _selectionRect; // expected-note {{property synthesized here}}
|
2009-04-11 06:42:54 +08:00
|
|
|
@end
|
|
|
|
|