| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 136658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
@interface Foo : NSObject
@property (readonly) id myProp;
@end
@implementation Foo
@synthesize myProp;
@end
t.m:9:13: error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute
@synthesize myProp;
^
which is fine, we want the ownership of the synthesized ivar to be explicit. But we should _not_ emit an error
for the following cases, because we can get the ownership either from the declared ivar or from the property type:
@interface Foo : NSObject {
__weak id _myProp1;
id myProp2;
}
@property (readonly) id myProp1;
@property (readonly) id myProp2;
@property (readonly) __strong id myProp3;
@end
@implementation Foo
@synthesize myProp1 = _myProp1;
@synthesize myProp2;
@synthesize myProp3;
@end

rdar://9844006.
llvm-svn: 136155
|
|
|
|
|
|
|
|
|
|
| |
C function) implementation
will be rejected with a compilation error in ARC mode, and a compiler warning otherwise.
This may cause breakage in non-arc (and arc) tests which don't expect warning/error. Feel free
to fix the tests, or reverse the patch, if I am unavailable. // rdar://9818354 - WIP
llvm-svn: 135740
|
|
|
|
|
|
| |
attributes. Fixes <rdar://problem/9561076>.
llvm-svn: 135273
|
|
|
|
|
|
|
| |
Make it also available in ObjC++ propeties. Use common code for
objc and objc++ so they don't diverge. // rdar://9740328
llvm-svn: 135050
|
|
|
|
|
|
| |
Make it also available in ObjC++ propeties. // rdar://9740328
llvm-svn: 135001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it, not at its declaration.
For this sample:
@interface Foo
@property id x;
@end
we get:
t.m:2:1: error: ARC forbids properties of Objective-C objects with unspecified storage attribute
@property id x;
^
1 error generated.
The error should be imposed on the implementor of the interface, not the user. If the user uses
a header of a non-ARC library whose source code he does not have, we are basically asking him to
go change the header of the library (bad in general), possible overriding how the property is
implemented if he gets confused and says "Oh I'll just add 'copy' then" (even worse).
Second issue is that we don't emit any error for 'readonly' properties, e.g:
@interface Foo
@property (readonly) id x; // no error here
@end
@implementation Foo
@synthesize x; // no error here too
@end
We should give an error when the implementor is @synthesizing a property which doesn't have
any storage specifier; this is when the explicit specifier is important, because we are
going to create an ivar and we want its ownership to be explicit.
Related improvements:
-OBJC_PR_unsafe_unretained turned out to not fit in ObjCPropertyDecl's bitfields, fix it.
-For properties of extension classes don't drop PropertyAttributesAsWritten values.
-Have PropertyAttributesAsWritten actually only reflect what the user wrote
rdar://9756610.
llvm-svn: 134960
|
|
|
|
|
|
|
|
|
|
|
|
| |
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
|
|
|
|
|
|
|
|
|
| |
to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091
llvm-svn: 133849
|
|
|
|
|
|
| |
is not implemented. // rdar://9651605
llvm-svn: 133819
|
|
|
|
|
|
|
|
| |
'ownership', not 'lifetime'.
rdar://9477613.
llvm-svn: 133779
|
|
|
|
|
|
|
|
|
|
| |
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
|
|
|
|
|
|
| |
properties.
llvm-svn: 132866
|
|
|
|
|
|
|
| |
It is not a sanctioned keyword and is assumed as default.
// rdar://8790791
llvm-svn: 132753
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
|
|
|
|
|
| |
Add a test case for synthesize ivar. // rdar://9070460
llvm-svn: 128554
|
|
|
|
|
|
|
| |
an executable test to llvm test suite.
// rdar://9070460.
llvm-svn: 128435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
|
|
|
|
| |
llvm-svn: 127225
|
|
|
|
| |
llvm-svn: 124620
|
|
|
|
|
|
|
|
|
|
|
| |
has custom getter or setter.
The rationale is that it is highly likely that the user's getter/setter isn't atomically implemented. Off by default.
Addresses rdar://8782645.
-Wcustom-atomic-properties and -Wimplicit-atomic-properties are under the -Watomic-properties group.
llvm-svn: 124609
|
|
|
|
|
|
|
|
| |
might be queried in places where we absolutely require a valid
location (e.g., for template instantiation). Fixes some major
brokenness in the use of __is_convertible_to.
llvm-svn: 124465
|
|
|
|
| |
llvm-svn: 123948
|
|
|
|
|
|
| |
property when it is 'readonly'. // rdar://8820813
llvm-svn: 122923
|
|
|
|
|
|
| |
-fobjc-default-synthesize-properties flag.
llvm-svn: 122757
|
|
|
|
|
|
|
| |
implicitly atomic under -Wimplicit-atomic-properties
flag. // rdar://8774580
llvm-svn: 122095
|
|
|
|
|
|
|
| |
created for auto-synthesis are @private.
Fixes: // rdar://8769582
llvm-svn: 121913
|
|
|
|
|
|
|
|
|
|
|
| |
declared setter or getter in current class extension or one
of the other class extensions. Mark them as synthesized as
property will be synthesized when property with same name is
seen in the @implementation. This prevents bogus warning
about unimplemented methods to be issued for these methods.
Fixes // rdar://8747333
llvm-svn: 121597
|
|
|
|
|
|
| |
reason this is limited to C++, and it's certainly not limited to temporaries.
llvm-svn: 120996
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
|
|
|
|
|
|
|
|
|
| |
@synthesize foo = _foo;
keep track of the location of the ivar ("_foo"). Teach libclang to
visit the ivar as a member reference.
llvm-svn: 119447
|
|
|
|
| |
llvm-svn: 119326
|
|
|
|
| |
llvm-svn: 119138
|
|
|
|
|
|
| |
other class extensions. // rdar://7629420
llvm-svn: 118689
|
|
|
|
|
|
|
|
|
|
| |
@property declaration to the autogenerated methods. I'm uncertain
whether this should apply to attributes in general, but these are
a reasonable core.
Implements rdar://problem/8617301
llvm-svn: 118676
|
|
|
|
|
|
|
|
|
|
| |
where the redelcaration and original
declaration have the 'readwrite' attribute. This is a common case, and we can issue a more lucid diagnostic.
Fixes <rdar://problem/7629420>.
llvm-svn: 117045
|
|
|
|
|
|
|
|
|
| |
find a copy constructor/assignment operator used
in getter/setter synthesis. This removes an unintended
diagnostics and makes objc++ consistant with objective-c.
// rdar: //8550657.
llvm-svn: 116631
|
|
|
|
| |
llvm-svn: 116519
|
|
|
|
|
|
|
|
|
| |
the location of the @implementation
is just confusing for clients that want to use SourceLocations for syntactic references.
Fixes: <rdar://problem/8470540>
llvm-svn: 114714
|
|
|
|
|
|
|
|
|
| |
use the class extension
as the lexical DeclContext for the @property declaration that gets auto-created for the @interface.
Fixes: <rdar://problem/8467189>
llvm-svn: 114693
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods declared with @property in class extensions.
This matches the behavior for setters.
Also pass the class extension to ProcessPropertyDecl as the lexical DeclContext, even when not redeclaring the @property.
This fixes the remaining issues in <rdar://problem/7410145>.
llvm-svn: 114477
|
|
|
|
|
|
|
|
|
|
|
| |
lexical DeclContext for newly created
ObjCMethodDecls. Further, use the location of the new property declaration as the location of new ObjCMethodDecls
(if they didn't previously exist).
This fixes more of the issues reported in <rdar://problem/7410145>.
llvm-svn: 114456
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ReferencedProtocols and AllReferencedProtocols. ReferencedProtocols
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
|
|
|
|
|
|
| |
This lets us remove Sema.h's dependency on Expr.h and Decl.h.
llvm-svn: 112156
|
|
|
|
|
|
|
| |
Clients of Sema don't need to know (for example) the list of diagnostics we
support.
llvm-svn: 112093
|
|
|
|
|
|
| |
to the new constants.
llvm-svn: 112047
|
|
|
|
| |
llvm-svn: 112030
|
|
|
|
|
|
|
| |
has its own getter and setter methods declared.
Fixed 8349319 (nonfragile-abi2).
llvm-svn: 112003
|
|
|
|
|
|
|
|
| |
previous use of a synthesized 'ivar' with property of same name
declared as @dynamic. In this case, 'ivar' is in the
inherited class and no diagnostics should be issued.
llvm-svn: 111940
|
|
|
|
| |
llvm-svn: 111904
|