From 13cc256e404620c1de0cbcc4e43ce1e2dbbc4898 Mon Sep 17 00:00:00 2001 From: Dimitry Andric Date: Sun, 2 Dec 2012 13:20:44 +0000 Subject: Vendor import of clang release_32 branch r168974 (effectively, 3.2 RC2): http://llvm.org/svn/llvm-project/cfe/branches/release_32@168974 --- docs/AutomaticReferenceCounting.html | 43 ++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) (limited to 'docs/AutomaticReferenceCounting.html') diff --git a/docs/AutomaticReferenceCounting.html b/docs/AutomaticReferenceCounting.html index 3f1ccaf672ca8..5354f8af34667 100644 --- a/docs/AutomaticReferenceCounting.html +++ b/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.

+

Applying __attribute__((NSObject)) 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 assign. 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.

+ @@ -1602,6 +1611,36 @@ implementation must be very careful to do all the other work that NSObject's dealloc would, which is outside the scope of this document to describe.

+

The instance variables for an ARC-compiled class will be destroyed +at some point after control enters the dealloc method for the +root class of the class. The ordering of the destruction of instance +variables is unspecified, both within a single class and between +subclasses and superclasses.

+ +

Rationale: the traditional, non-ARC pattern +for destroying instance variables is to destroy them immediately +before calling [super dealloc]. Unfortunately, message +sends from the superclass are quite capable of reaching methods in the +subclass, and those methods may well read or write to those instance +variables. Making such message sends from dealloc is generally +discouraged, since the subclass may well rely on other invariants that +were broken during dealloc, but it's not so inescapably +dangerous that we felt comfortable calling it undefined behavior. +Therefore we chose to delay destroying the instance variables to a +point at which message sends are clearly disallowed: the point at +which the root class's deallocation routines take over.

+ +

In most code, the difference is not observable. It can, however, +be observed if an instance variable holds a strong reference to an +object whose deallocation will trigger a side-effect which must be +carefully ordered with respect to the destruction of the super class. +Such code violates the design principle that semantically important +behavior should be explicit. A simple fix is to clear the instance +variable manually during dealloc; a more holistic solution is +to move semantically important side-effects out of +dealloc and into a separate teardown phase which can rely on +working with well-formed objects.

+ @@ -1865,9 +1904,9 @@ and cf_unknown_transfer.

A pragma is provided to facilitate the mass annotation of interfaces:

-
#pragma arc_cf_code_audited begin
+
#pragma clang arc_cf_code_audited begin
 ...
-#pragma arc_cf_code_audited end

+#pragma clang arc_cf_code_audited end

All C functions declared within the extent of this pragma are treated as if annotated with the cf_audited_transfer -- cgit v1.3