'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
Introduce and document a new objc_returns_inner_pointer
attribute, and consume it by performing a retain+autorelease
on message receivers when they're not immediately loaded from
an object with precise lifetime.
llvm-svn: 135764
One weird thing is the addition of several <a name=""> tags where
previously there were id attributes on the <h3> tags. This is because
the id attribute must begin with a letter, not an underscore. The name
attribute is not so constrained, so links will continue to work.
llvm-svn: 133677
silently dropped ownership qualifiers that were being applied to
ownership-qualified, substituted type that was *not* a substituted
template type parameter. We now provide a diagnostic in such cases,
and recover by dropping the added qualifiers.
Document this behavior in the ARC specification.
llvm-svn: 133309
ownership-unqualified retainable object type as __strong. This allows
us to write, e.g.,
std::vector<id>
and we'll infer that the vector's element types have __strong
ownership semantics, which is far nicer than requiring:
std::vector<__strong id>
Note that we allow one to override the ownership qualifier of a
substituted template type parameter, e.g., given
template<typename T>
struct X {
typedef __weak T type;
};
X<id> is treated the same as X<__strong id>. At instantiation type,
the __weak in "__weak T" overrides the (inferred or specified)
__strong on the template argument type, so that we can still provide
metaprogramming transformations.
This is part of <rdar://problem/9595486>.
llvm-svn: 133303
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
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
Patch by Matthieu Monrocq with tweaks by me to avoid StringRefs in the static
diagnostic data structures, which resulted in a huge global-var-init function.
Depends on llvm commit r132046.
llvm-svn: 132047
minor issues along the way:
- Non-type template parameters of type 'std::nullptr_t' were not
permitted.
- We didn't properly introduce built-in operators for nullptr ==,
!=, <, <=, >=, or > as candidate functions .
To my knowledge, there's only one (minor but annoying) part of nullptr
that hasn't been implemented: catching a thrown 'nullptr' as a pointer
or pointer-to-member, per C++0x [except.handle]p4.
llvm-svn: 131813
Douglas Gregor