overridden methods to diagnose their type mismatch.
This is a general solution for previous fixes
for // rdar://6191214 and // rdar://9352731
and removes lots of duplicate code.
llvm-svn: 137222
situation. When a class explicitly or implicitly (through inheritance)
"conformsTo" two protocols which conflict (have methods which conflict).
This patch fixes the previous patch where warnings were coming out in
non-deterministic order. This is 2nd part of // rdar://6191214.
llvm-svn: 137055
ActOnStartOfSwitchStmt (i.e. before binding up a full-expression)
instead of ActOnFinishSwitchStmt.
Among other things, this means that property l-values are properly
converted inside the full-expression.
llvm-svn: 137014
situation. When a class explicitly or implicitly (through inheritance)
"conformsTo" two protocols which conflict (have methods which conflict).
This is 2nd part of // rdar://6191214.
llvm-svn: 136927
special diagnostic for ARC ownership-qualified types. We wouldn't want
to expose Objective-C programmers to the term "POD", would we? Fixes
<rdar://problem/9772982>.
llvm-svn: 136558
masks an existing method in its primary class, class extensions,
and primary class's non-optional protocol methods; as primary
class, or one of its subclass's will implement this method.
This warning has potential of being noisy so it has its own
group. // rdar://7020493
llvm-svn: 136426
for-in statements; specifically, make sure to close over any
temporaries or cleanups it might require. In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.
rdar://problem/9817306
llvm-svn: 136204
@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
declared in protocol in the class qualified by the
protocol have type conflicts. To reduce amount of
noise, this is done when class is implemented.
// rdar://9352731
llvm-svn: 135890
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
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
llvm-svn: 135051
block pointers) that don't have any qualification to be POD types. We
were previously considering them to be non-POD types, because this was
convenient in C++ for is_pod-like traits. However, we now end up
inferring lifetime in such cases (template arguments infer __strong),
so it is not necessary.
Moreover, we want rvalues of object type (which have their lifetime
stripped) to be PODs to allow, e.g., va_arg(arglist, id) to function
properly. Fixes <rdar://problem/9758798>.
llvm-svn: 134993
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
require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.
llvm-svn: 134906
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
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
(NSString**)&x; // Casting as (__strong NSString**).
llvm-svn: 134275
specifiers. Fixes <rdar://problem/9607158>." because it causes false positives
on some code that uses CF toll free bridging.
- I'll let Doug or Ted figure out the right fix here, possibly just to accept
any pointer type.
llvm-svn: 134041
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
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
Fariborz Jahanian