> 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
> <mailto:rjmcc...@apple.com>> wrote:
> > On Oct 30, 2015, at 5:39 PM, Nico Weber <tha...@chromium.org
> > <mailto: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)
John.
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
