forked from OSchip/llvm-project
Document -fobjc-weak as an extension.
Fixes rdar://24091053. llvm-svn: 337525
This commit is contained in:
parent
07fa4a49c4
commit
ea9c580994
|
@ -1200,6 +1200,51 @@ Objective-C objects. ``__has_feature(objc_arc_fields)`` indicates that C structs
|
||||||
are allowed to have fields that are pointers to Objective-C objects managed by
|
are allowed to have fields that are pointers to Objective-C objects managed by
|
||||||
automatic reference counting.
|
automatic reference counting.
|
||||||
|
|
||||||
|
.. _objc-weak:
|
||||||
|
|
||||||
|
Weak references
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Clang supports ARC-style weak and unsafe references in Objective-C even
|
||||||
|
outside of ARC mode. Weak references must be explicitly enabled with
|
||||||
|
the ``-fobjc-weak`` option; use ``__has_feature((objc_arc_weak))``
|
||||||
|
to test whether they are enabled. Unsafe references are enabled
|
||||||
|
unconditionally. ARC-style weak and unsafe references cannot be used
|
||||||
|
when Objective-C garbage collection is enabled.
|
||||||
|
|
||||||
|
Except as noted below, the language rules for the ``__weak`` and
|
||||||
|
``__unsafe_unretained`` qualifiers (and the ``weak`` and
|
||||||
|
``unsafe_unretained`` property attributes) are just as laid out
|
||||||
|
in the :doc:`ARC specification <AutomaticReferenceCounting>`.
|
||||||
|
In particular, note that some classes do not support forming weak
|
||||||
|
references to their instances, and note that special care must be
|
||||||
|
taken when storing weak references in memory where initialization
|
||||||
|
and deinitialization are outside the responsibility of the compiler
|
||||||
|
(such as in ``malloc``-ed memory).
|
||||||
|
|
||||||
|
Loading from a ``__weak`` variable always implicitly retains the
|
||||||
|
loaded value. In non-ARC modes, this retain is normally balanced
|
||||||
|
by an implicit autorelease. This autorelease can be suppressed
|
||||||
|
by performing the load in the receiver position of a ``-retain``
|
||||||
|
message send (e.g. ``[weakReference retain]``); note that this performs
|
||||||
|
only a single retain (the retain done when primitively loading from
|
||||||
|
the weak reference).
|
||||||
|
|
||||||
|
For the most part, ``__unsafe_unretained`` in non-ARC modes is just the
|
||||||
|
default behavior of variables and therefore is not needed. However,
|
||||||
|
it does have an effect on the semantics of block captures: normally,
|
||||||
|
copying a block which captures an Objective-C object or block pointer
|
||||||
|
causes the captured pointer to be retained or copied, respectively,
|
||||||
|
but that behavior is suppressed when the captured variable is qualified
|
||||||
|
with ``__unsafe_unretained``.
|
||||||
|
|
||||||
|
Note that the ``__weak`` qualifier formerly meant the GC qualifier in
|
||||||
|
all non-ARC modes and was silently ignored outside of GC modes. It now
|
||||||
|
means the ARC-style qualifier in all non-GC modes and is no longer
|
||||||
|
allowed if not enabled by either ``-fobjc-arc`` or ``-fobjc-weak``.
|
||||||
|
It is expected that ``-fobjc-weak`` will eventually be enabled by default
|
||||||
|
in all non-GC Objective-C modes.
|
||||||
|
|
||||||
.. _objc-fixed-enum:
|
.. _objc-fixed-enum:
|
||||||
|
|
||||||
Enumerations with a fixed underlying type
|
Enumerations with a fixed underlying type
|
||||||
|
|
Loading…
Reference in New Issue