On Mon, Nov 2, 2015 at 3:00 PM, John McCall <rjmcc...@apple.com> wrote:
> On Nov 2, 2015, at 2:53 PM, Nico Weber <tha...@chromium.org> wrote: > On Fri, Oct 30, 2015 at 5:55 PM, John McCall <rjmcc...@apple.com> wrote: > >> > On Oct 30, 2015, at 5:39 PM, Nico Weber <tha...@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!
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits