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

[John McCall via cfe-commits]

> 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.

John.