r251041 - Define weak and __weak to mean ARC-style weak references, even in MRC.

[Nico Weber via cfe-commits]

On Mon, Nov 2, 2015 at 3:00 PM, John McCall <rjmccall at apple.com> wrote:

> On Nov 2, 2015, at 2:53 PM, Nico Weber <thakis at chromium.org> wrote:
> On Fri, Oct 30, 2015 at 5:55 PM, John McCall <rjmccall at apple.com> wrote:
>
>> > On Oct 30, 2015, at 5:39 PM, Nico Weber <thakis at chromium.org> wrote:
>> > Hi John,
>> >
>> > this breaks programs that use __weak and target 10.6, like so:
>> >
>> > $ cat test.m
>> > #import <Foundation/Foundation.h>
>> > @interface I : NSObject {
>> >   __weak NSObject* foo_;
>> > }
>> > - (NSObject*)foo;
>> > @end
>> >
>> > @implementation I
>> > - (NSObject *)foo {
>> >   return foo_;
>> > }
>> > @end
>> > $ clang -c test.m -mmacosx-version-min=10.6  # works with Xcode's clang
>> > $ ~/src/llvm-build/bin/clang -c test.m -isysroot $(xcrun
>> -show-sdk-path) -mmacosx-version-min=10.6
>> > test.m:10:10: error: 'foo_' is unavailable: cannot use weak references
>> because the current deployment target does not support them
>> >   return foo_;
>> >          ^
>> > test.m:3:20: note: unsupported declaration here
>> >   __weak NSObject* foo_;
>> >                    ^
>> > test.m:3:20: error: cannot create __weak reference because the current
>> deployment target does not support weak references
>> >   __weak NSObject* foo_;
>> >                    ^
>> > 2 errors generated.
>> >
>> >
>> > We target 10.6 (and don't use ARC) and some library we use has __weak
>> ivars. After this change, we can't build it any longer. This isn't a huge
>> issue: we can change the library to use a WEAK macro that expands to
>> nothing for us and __weak if ARC is enabled, but it sounded like you're
>> interested in hearing about this.
>>
>> This is intended behavior.  We are changing __weak in non-ARC, non-GC TUs
>> (i.e. MRC) to mean ARC-style __weak references.  Since, previously, __weak
>> was accepted but silently ignored in MRC, there will be a period of time
>> during which __weak will simply be rejected by the compiler in this mode.
>> The compiler does try to be conservative about variables that are actually
>> defined in other translation units, but in this case you are defining (and
>> using) the ivar in the current TU, and you need to be aware that the
>> semantics of that are changing.
>>
>> If the library is quite old, it may be using __weak in the GC sense, in
>> which case you can probably just remove it.  If the library is new, and it
>> really wants an ARC weak reference, then you may want your macro to expand
>> to __unsafe_unretained, just in case there are files in that project that
>> do use ARC.
>>
>
> Thanks. Is the plan to also add a __has_feature check added when __weak
> becomes available in MRC mode (say, __has_feature(mrc_weak) or similar)?
>
>
> Our plan was to spell this check:
>   __has_feature(objc_arc_weak) && !__has_feature(objc_arc)
>

Ah, that makes sense. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151102/98c75f3b/attachment.html>