Fix a pair of bugs relating to properties in ARC.

First, when synthesizing an explicitly strong/retain/copy property
of Class type, don't pretend during compatibility checking that the
property is actually assign.  Instead, resolve incompatibilities
by secretly changing the type of *implicitly* __unsafe_unretained
Class ivars to be strong.  This is moderately evil but better than
what we were doing.

Second, when synthesizing the setter for a strong property of
non-retainable type, be sure to use objc_setProperty.  This is
possible when the property is decorated with the NSObject
attribute.  This is an ugly, ugly corner of the language, and
we probably ought to deprecate it.

The first is rdar://problem/12039404;  the second was noticed by
inspection while fixing the first.

llvm-svn: 162244

1 files changed, 9 insertions, 0 deletions

diff --git a/clang/docs/AutomaticReferenceCounting.html b/clang/docs/AutomaticReferenceCounting.html
index 3f1ccaf672c..2fd82dda65c 100644
--- a/clang/docs/AutomaticReferenceCounting.html
+++ b/clang/docs/AutomaticReferenceCounting.html
@@ -888,6 +888,15 @@ from non-ARC practice was acceptable because we had conservatively
 banned the synthesis in order to give ourselves exactly this
 leeway.</p></div>
 
+<p>Applying <tt>__attribute__((NSObject))</tt> to a property not of
+retainable object pointer type has the same behavior it does outside
+of ARC:  it requires the property type to be some sort of pointer and
+permits the use of modifiers other than <tt>assign</tt>.  These
+modifiers only affect the synthesized getter and setter; direct
+accesses to the ivar (even if synthesized) still have primitive
+semantics, and the value in the ivar will not be automatically
+released during deallocation.</p>
+
 </div> <!-- ownership.spelling.property -->
 
 </div> <!-- ownership.spelling -->