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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162244 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/docs/AutomaticReferenceCounting.html b/docs/AutomaticReferenceCounting.html
index 3f1ccaf..2fd82dd 100644
--- a/docs/AutomaticReferenceCounting.html
+++ b/docs/AutomaticReferenceCounting.html
@@ -888,6 +888,15 @@
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 -->