Commit Graph

3 Commits

Author SHA1 Message Date
John McCall 00b2bbb7bb Don't actually add the __unsafe_unretained qualifier in MRC;
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid.  Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures.  The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.

llvm-svn: 253534
2015-11-19 02:28:03 +00:00
John McCall d80218fa42 Fix the emission of ARC-style ivar layouts in the fragile runtime
to start at the offset of the first ivar instead of the rounded-up
end of the superclass.  The latter could include a large amount of
tail padding because of a highly-aligned ivar, and subclass ivars
can be laid out within that.

llvm-svn: 253533
2015-11-19 02:27:55 +00:00
John McCall 460ce58fa6 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-22 18:38:17 +00:00