[llvm-branch-commits] [clang] [docs] Finish MyST migration for selected Clang docs (PR #214617)
via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Fri Aug 7 14:52:27 PDT 2026
llvmorg-github-actions[bot] wrote:
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-hlsl
Author: Reid Kleckner (rnk)
<details>
<summary>Changes</summary>
Tracking issue: #<!-- -->201242
See the [migration guide] for more information.
[migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines
This is a stacked PR based on #<!-- -->214615 , which will be a standalone commit that
renames *.rst -> *.md before this PR lands for history preservation purposes.
This was prepared with rst2myst plus LLM-assisted cleanup. I paged through all the generated HTML looking for migration artifacts, and all of the differences I could find appear to be formatting error corrections. Please spot check my work and approve if it looks good. You can use the HTML links below to confirm it renders properly.
-----
Before/after validation links:
| Source file | Before HTML | After HTML |
| --- | --- | --- |
| `clang/docs/AutomaticReferenceCounting.md` | [before](https://clang.llvm.org/docs/AutomaticReferenceCounting.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/AutomaticReferenceCounting.html) |
| `clang/docs/Block-ABI-Apple.md` | [before](https://clang.llvm.org/docs/Block-ABI-Apple.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/Block-ABI-Apple.html) |
| `clang/docs/BlockLanguageSpec.md` | [before](https://clang.llvm.org/docs/BlockLanguageSpec.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/BlockLanguageSpec.html) |
| `clang/docs/CIR/ABILowering.md` | [before](https://clang.llvm.org/docs/CIR/ABILowering.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CIR/ABILowering.html) |
| `clang/docs/CIR/CleanupAndEHDesign.md` | [before](https://clang.llvm.org/docs/CIR/CleanupAndEHDesign.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CIR/CleanupAndEHDesign.html) |
| `clang/docs/CIR/CodeDuplication.md` | [before](https://clang.llvm.org/docs/CIR/CodeDuplication.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CIR/CodeDuplication.html) |
| `clang/docs/CommandGuide/clang.md` | [before](https://clang.llvm.org/docs/CommandGuide/clang.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CommandGuide/clang.html) |
| `clang/docs/CommandGuide/diagtool.md` | [before](https://clang.llvm.org/docs/CommandGuide/diagtool.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CommandGuide/diagtool.html) |
| `clang/docs/ConstantInterpreter.md` | [before](https://clang.llvm.org/docs/ConstantInterpreter.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ConstantInterpreter.html) |
| `clang/docs/ControlFlowIntegrityDesign.md` | [before](https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ControlFlowIntegrityDesign.html) |
| `clang/docs/DataFlowSanitizerDesign.md` | [before](https://clang.llvm.org/docs/DataFlowSanitizerDesign.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/DataFlowSanitizerDesign.html) |
| `clang/docs/HLSL/AvailabilityDiagnostics.md` | [before](https://clang.llvm.org/docs/HLSL/AvailabilityDiagnostics.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/AvailabilityDiagnostics.html) |
| `clang/docs/HLSL/EntryFunctions.md` | [before](https://clang.llvm.org/docs/HLSL/EntryFunctions.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/EntryFunctions.html) |
| `clang/docs/HLSL/ExpectedDifferences.md` | [before](https://clang.llvm.org/docs/HLSL/ExpectedDifferences.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/ExpectedDifferences.html) |
| `clang/docs/HLSL/FunctionCalls.md` | [before](https://clang.llvm.org/docs/HLSL/FunctionCalls.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/FunctionCalls.html) |
| `clang/docs/HLSL/HLSLIRReference.md` | [before](https://clang.llvm.org/docs/HLSL/HLSLIRReference.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/HLSLIRReference.html) |
| `clang/docs/HLSL/HLSLSupport.md` | [before](https://clang.llvm.org/docs/HLSL/HLSLSupport.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/HLSLSupport.html) |
| `clang/docs/HLSL/ResourceTypes.md` | [before](https://clang.llvm.org/docs/HLSL/ResourceTypes.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HLSL/ResourceTypes.html) |
| `clang/docs/HardwareAssistedAddressSanitizerDesign.md` | [before](https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/HardwareAssistedAddressSanitizerDesign.html) |
| `clang/docs/ItaniumMangleAbiTags.md` | [before](https://clang.llvm.org/docs/ItaniumMangleAbiTags.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ItaniumMangleAbiTags.html) |
---
Patch is 671.48 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/214617.diff
20 Files Affected:
- (modified) clang/docs/AutomaticReferenceCounting.md (+1567-1650)
- (modified) clang/docs/Block-ABI-Apple.md (+682-706)
- (modified) clang/docs/BlockLanguageSpec.md (+131-147)
- (modified) clang/docs/CIR/ABILowering.md (+344-376)
- (modified) clang/docs/CIR/CleanupAndEHDesign.md (+1101-1131)
- (modified) clang/docs/CIR/CodeDuplication.md (+22-28)
- (modified) clang/docs/CommandGuide/clang.md (+636-701)
- (modified) clang/docs/CommandGuide/diagtool.md (+23-31)
- (modified) clang/docs/ConstantInterpreter.md (+141-165)
- (modified) clang/docs/ControlFlowIntegrityDesign.md (+387-409)
- (modified) clang/docs/DataFlowSanitizerDesign.md (+155-179)
- (modified) clang/docs/HLSL/AvailabilityDiagnostics.md (+73-83)
- (modified) clang/docs/HLSL/EntryFunctions.md (+31-35)
- (modified) clang/docs/HLSL/ExpectedDifferences.md (+134-141)
- (modified) clang/docs/HLSL/FunctionCalls.md (+203-212)
- (modified) clang/docs/HLSL/HLSLIRReference.md (+10-13)
- (modified) clang/docs/HLSL/HLSLSupport.md (+77-100)
- (modified) clang/docs/HLSL/ResourceTypes.md (+9-11)
- (modified) clang/docs/HardwareAssistedAddressSanitizerDesign.md (+159-178)
- (modified) clang/docs/ItaniumMangleAbiTags.md (+40-48)
``````````diff
diff --git a/clang/docs/AutomaticReferenceCounting.md b/clang/docs/AutomaticReferenceCounting.md
index 4a97cac7b2615..5e09af834e3a3 100644
--- a/clang/docs/AutomaticReferenceCounting.md
+++ b/clang/docs/AutomaticReferenceCounting.md
@@ -1,185 +1,185 @@
-.. FIXME: move to the stylesheet or Sphinx plugin
-
-.. raw:: html
-
- <style>
- .arc-term { font-style: italic; font-weight: bold; }
- .revision { font-style: italic; }
- .when-revised { font-weight: bold; font-style: normal; }
-
- /*
- * Automatic numbering is described in this article:
- * https://dev.opera.com/articles/view/automatic-numbering-with-css-counters/
- */
- /*
- * Automatic numbering for the TOC.
- * This is wrong from the semantics point of view, since it is an ordered
- * list, but uses "ul" tag.
- */
- div#contents.contents.local ul {
- counter-reset: toc-section;
- list-style-type: none;
- }
- div#contents.contents.local ul li {
- counter-increment: toc-section;
- background: none; // Remove bullets
- }
- div#contents.contents.local ul li a.reference:before {
- content: counters(toc-section, ".") " ";
- }
-
- /* Automatic numbering for the body. */
- body {
- counter-reset: section subsection subsubsection;
- }
- .section h2 {
- counter-reset: subsection subsubsection;
- counter-increment: section;
- }
- .section h2 a.toc-backref:before {
- content: counter(section) " ";
- }
- .section h3 {
- counter-reset: subsubsection;
- counter-increment: subsection;
- }
- .section h3 a.toc-backref:before {
- content: counter(section) "." counter(subsection) " ";
- }
- .section h4 {
- counter-increment: subsubsection;
- }
- .section h4 a.toc-backref:before {
- content: counter(section) "." counter(subsection) "." counter(subsubsection) " ";
- }
- </style>
-
-.. role:: arc-term
-.. role:: revision
-.. role:: when-revised
-
-==============================================
-Objective-C Automatic Reference Counting (ARC)
-==============================================
-
-.. contents::
- :local:
-
-.. _arc.meta:
-
-About this document
-===================
-
-.. _arc.meta.purpose:
-
-Purpose
--------
+% FIXME: move to the stylesheet or Sphinx plugin
+
+```{raw} html
+<style>
+ .arc-term { font-style: italic; font-weight: bold; }
+ .revision { font-style: italic; }
+ .when-revised { font-weight: bold; font-style: normal; }
+
+ /*
+ * Automatic numbering is described in this article:
+ * https://dev.opera.com/articles/view/automatic-numbering-with-css-counters/
+ */
+ /*
+ * Automatic numbering for the TOC.
+ * This is wrong from the semantics point of view, since it is an ordered
+ * list, but uses "ul" tag.
+ */
+ div#contents.contents.local ul {
+ counter-reset: toc-section;
+ list-style-type: none;
+ }
+ div#contents.contents.local ul li {
+ counter-increment: toc-section;
+ background: none; // Remove bullets
+ }
+ div#contents.contents.local ul li a.reference:before {
+ content: counters(toc-section, ".") " ";
+ }
+
+ /* Automatic numbering for the body. */
+ body {
+ counter-reset: section subsection subsubsection;
+ }
+ .section h2 {
+ counter-reset: subsection subsubsection;
+ counter-increment: section;
+ }
+ .section h2 a.toc-backref:before {
+ content: counter(section) " ";
+ }
+ .section h3 {
+ counter-reset: subsubsection;
+ counter-increment: subsection;
+ }
+ .section h3 a.toc-backref:before {
+ content: counter(section) "." counter(subsection) " ";
+ }
+ .section h4 {
+ counter-increment: subsubsection;
+ }
+ .section h4 a.toc-backref:before {
+ content: counter(section) "." counter(subsection) "." counter(subsubsection) " ";
+ }
+</style>
+```
+
+```{role} arc-term
+```
+
+```{role} revision
+```
+
+```{role} when-revised
+```
+
+# Objective-C Automatic Reference Counting (ARC)
+
+```{contents}
+:local: true
+```
+
+(arc.meta)=
+
+## About this document
+
+(arc.meta.purpose)=
+
+### Purpose
The first and primary purpose of this document is to serve as a complete
-technical specification of Automatic Reference Counting. Given a core
+technical specification of Automatic Reference Counting. Given a core
Objective-C compiler and runtime, it should be possible to write a compiler and
runtime which implements these new semantics.
The secondary purpose is to act as a rationale for why ARC was designed in this
-way. This should remain tightly focused on the technical design and should not
+way. This should remain tightly focused on the technical design and should not
stray into marketing speculation.
-.. _arc.meta.background:
+(arc.meta.background)=
-Background
-----------
+### Background
This document assumes a basic familiarity with C.
-:arc-term:`Blocks` are a C language extension for creating anonymous functions.
-Users interact with and transfer block objects using :arc-term:`block
-pointers`, which are represented like a normal pointer. A block may capture
+{arc-term}`Blocks` are a C language extension for creating anonymous functions.
+Users interact with and transfer block objects using {arc-term}`block
+pointers`, which are represented like a normal pointer. A block may capture
values from local variables; when this occurs, memory must be dynamically
-allocated. The initial allocation is done on the stack, but the runtime
-provides a ``Block_copy`` function which, given a block pointer, either copies
+allocated. The initial allocation is done on the stack, but the runtime
+provides a `Block_copy` function which, given a block pointer, either copies
the underlying block object to the heap, setting its reference count to 1 and
returning the new block pointer, or (if the block object is already on the
-heap) increases its reference count by 1. The paired function is
-``Block_release``, which decreases the reference count by 1 and destroys the
+heap) increases its reference count by 1. The paired function is
+`Block_release`, which decreases the reference count by 1 and destroys the
object if the count reaches zero and is on the heap.
Objective-C is a set of language extensions, significant enough to be
-considered a different language. It is a strict superset of C. The extensions
-can also be imposed on C++, producing a language called Objective-C++. The
+considered a different language. It is a strict superset of C. The extensions
+can also be imposed on C++, producing a language called Objective-C++. The
primary feature is a single-inheritance object system; we briefly describe the
modern dialect.
-Objective-C defines a new type kind, collectively called the :arc-term:`object
-pointer types`. This kind has two notable builtin members, ``id`` and
-``Class``; ``id`` is the final supertype of all object pointers. The validity
-of conversions between object pointer types is not checked at runtime. Users
-may define :arc-term:`classes`; each class is a type, and the pointer to that
-type is an object pointer type. A class may have a superclass; its pointer
-type is a subtype of its superclass's pointer type. A class has a set of
-:arc-term:`ivars`, fields which appear on all instances of that class. For
+Objective-C defines a new type kind, collectively called the {arc-term}`object
+pointer types`. This kind has two notable builtin members, `id` and
+`Class`; `id` is the final supertype of all object pointers. The validity
+of conversions between object pointer types is not checked at runtime. Users
+may define {arc-term}`classes`; each class is a type, and the pointer to that
+type is an object pointer type. A class may have a superclass; its pointer
+type is a subtype of its superclass's pointer type. A class has a set of
+{arc-term}`ivars`, fields which appear on all instances of that class. For
every class *T* there's an associated metaclass; it has no fields, its
superclass is the metaclass of *T*'s superclass, and its metaclass is a global
-class. Every class has a global object whose class is the class's metaclass;
+class. Every class has a global object whose class is the class's metaclass;
metaclasses have no associated type, so pointers to this object have type
-``Class``.
+`Class`.
-A class declaration (``@interface``) declares a set of :arc-term:`methods`. A
-method has a return type, a list of argument types, and a :arc-term:`selector`:
-a name like ``foo:bar:baz:``, where the number of colons corresponds to the
-number of formal arguments. A method may be an instance method, in which case
+A class declaration (`@interface`) declares a set of {arc-term}`methods`. A
+method has a return type, a list of argument types, and a {arc-term}`selector`:
+a name like `foo:bar:baz:`, where the number of colons corresponds to the
+number of formal arguments. A method may be an instance method, in which case
it can be invoked on objects of the class, or a class method, in which case it
-can be invoked on objects of the metaclass. A method may be invoked by
-providing an object (called the :arc-term:`receiver`) and a list of formal
+can be invoked on objects of the metaclass. A method may be invoked by
+providing an object (called the {arc-term}`receiver`) and a list of formal
arguments interspersed with the selector, like so:
-.. code-block:: objc
-
- [receiver foo: fooArg bar: barArg baz: bazArg]
+```objc
+[receiver foo: fooArg bar: barArg baz: bazArg]
+```
This looks in the dynamic class of the receiver for a method with this name,
then in that class's superclass, etc., until it finds something it can execute.
The receiver "expression" may also be the name of a class, in which case the
actual receiver is the class object for that class, or (within method
-definitions) it may be ``super``, in which case the lookup algorithm starts
-with the static superclass instead of the dynamic class. The actual methods
-dynamically found in a class are not those declared in the ``@interface``, but
-those defined in a separate ``@implementation`` declaration; however, when
+definitions) it may be `super`, in which case the lookup algorithm starts
+with the static superclass instead of the dynamic class. The actual methods
+dynamically found in a class are not those declared in the `@interface`, but
+those defined in a separate `@implementation` declaration; however, when
compiling a call, typechecking is done based on the methods declared in the
-``@interface``.
+`@interface`.
-Method declarations may also be grouped into :arc-term:`protocols`, which are not
+Method declarations may also be grouped into {arc-term}`protocols`, which are not
inherently associated with any class, but which classes may claim to follow.
Object pointer types may be qualified with additional protocols that the object
is known to support.
-:arc-term:`Class extensions` are collections of ivars and methods, designed to
-allow a class's ``@interface`` to be split across multiple files; however,
+{arc-term}`Class extensions` are collections of ivars and methods, designed to
+allow a class's `@interface` to be split across multiple files; however,
there is still a primary implementation file which must see the
-``@interface``\ s of all class extensions. :arc-term:`Categories` allow
+`@interface`s of all class extensions. {arc-term}`Categories` allow
methods (but not ivars) to be declared *post hoc* on an arbitrary class; the
-methods in the category's ``@implementation`` will be dynamically added to that
+methods in the category's `@implementation` will be dynamically added to that
class's method tables which the category is loaded at runtime, replacing those
methods in case of a collision.
In the standard environment, objects are allocated on the heap, and their
-lifetime is manually managed using a reference count. This is done using two
-instance methods which all classes are expected to implement: ``retain``
-increases the object's reference count by 1, whereas ``release`` decreases it
-by 1 and calls the instance method ``dealloc`` if the count reaches 0. To
-simplify certain operations, there is also an :arc-term:`autorelease pool`, a
-thread-local list of objects to call ``release`` on later; an object can be
-added to this pool by calling ``autorelease`` on it.
-
-Block pointers may be converted to type ``id``; block objects are laid out in a
-way that makes them compatible with Objective-C objects. There is a builtin
+lifetime is manually managed using a reference count. This is done using two
+instance methods which all classes are expected to implement: `retain`
+increases the object's reference count by 1, whereas `release` decreases it
+by 1 and calls the instance method `dealloc` if the count reaches 0. To
+simplify certain operations, there is also an {arc-term}`autorelease pool`, a
+thread-local list of objects to call `release` on later; an object can be
+added to this pool by calling `autorelease` on it.
+
+Block pointers may be converted to type `id`; block objects are laid out in a
+way that makes them compatible with Objective-C objects. There is a builtin
class that all block objects are considered to be objects of; this class
-implements ``retain`` by adjusting the reference count, not by calling
-``Block_copy``.
+implements `retain` by adjusting the reference count, not by calling
+`Block_copy`.
-.. _arc.meta.evolution:
+(arc.meta.evolution)=
-Evolution
----------
+### Evolution
ARC is under continual evolution, and this document must be updated as the
language progresses.
@@ -188,199 +188,192 @@ If a change increases the expressiveness of the language, for example by
lifting a restriction or by adding new syntax, the change will be annotated
with a revision marker, like so:
- ARC applies to Objective-C pointer types, block pointer types, and
- :when-revised:`[beginning Apple 8.0, LLVM 3.8]` :revision:`BPTRs declared
- within` ``extern "BCPL"`` blocks.
+> ARC applies to Objective-C pointer types, block pointer types, and
+> {when-revised}`[beginning Apple 8.0, LLVM 3.8]` {revision}`BPTRs declared
+> within` `extern "BCPL"` blocks.
For now, it is sensible to version this document by the releases of its sole
-implementation (and its host project), clang. "LLVM X.Y" refers to an
-open-source release of clang from the LLVM project. "Apple X.Y" refers to an
-Apple-provided release of the Apple LLVM Compiler. Other organizations that
+implementation (and its host project), clang. "LLVM X.Y" refers to an
+open-source release of clang from the LLVM project. "Apple X.Y" refers to an
+Apple-provided release of the Apple LLVM Compiler. Other organizations that
prepare their own, separately-versioned clang releases and wish to maintain
similar information in this document should send requests to cfe-dev.
If a change decreases the expressiveness of the language, for example by
imposing a new restriction, this should be taken as an oversight in the
-original specification and something to be avoided in all versions. Such
+original specification and something to be avoided in all versions. Such
changes are generally to be avoided.
-.. _arc.general:
+(arc.general)=
-General
-=======
+## General
Automatic Reference Counting implements automatic memory management for
Objective-C objects and blocks, freeing the programmer from the need to
-explicitly insert retains and releases. It does not provide a cycle collector;
+explicitly insert retains and releases. It does not provide a cycle collector;
users must explicitly manage the lifetime of their objects, breaking cycles
manually or with weak or unsafe references.
-ARC may be explicitly enabled with the compiler flag ``-fobjc-arc``. It may
-also be explicitly disabled with the compiler flag ``-fno-objc-arc``. The last
+ARC may be explicitly enabled with the compiler flag `-fobjc-arc`. It may
+also be explicitly disabled with the compiler flag `-fno-objc-arc`. The last
of these two flags appearing on the compile line "wins".
-If ARC is enabled, ``__has_feature(objc_arc)`` will expand to 1 in the
-preprocessor. For more information about ``__has_feature``, see the
-:ref:`language extensions <langext-__has_feature-__has_extension>` document.
+If ARC is enabled, `__has_feature(objc_arc)` will expand to 1 in the
+preprocessor. For more information about `__has_feature`, see the
+{ref}`language extensions <langext-__has_feature-__has_extension>` document.
-.. _arc.objects:
+(arc.objects)=
-Retainable object pointers
-==========================
+## Retainable object pointers
This section describes retainable object pointers, their basic operations, and
-the restrictions imposed on their use under ARC. Note in particular that it
+the restrictions imposed on their use under ARC. Note in particular that it
covers the rules for pointer *values* (patterns of bits indicating the location
of a pointed-to object), not pointer *objects* (locations in memory which store
-pointer values). The rules for objects are covered in the next section.
+pointer values). The rules for objects are covered in the next section.
-A :arc-term:`retainable object pointer` (or "retainable pointer") is a value of
-a :arc-term:`retainable object pointer type` ("retainable type"). There are
+A {arc-term}`retainable object pointer` (or "retainable pointer") is a value of
+a {arc-term}`retainable object pointer type` ("retainable type"). There are
three kinds of retainable object pointer types:
-* block pointers (formed by applying the caret (``^``) declarator sigil to a
+- block pointers (formed by applying the caret (`^`) declarator sigil to a
function type)
-* Objective-C object pointers (``id``, ``Class``, ``NSFoo*``, etc.)
-* typedefs marked with ``__attribute__((NSObject))``
+- Objective-C object pointers (`id`, `Class`, `NSFoo*`, etc.)
+- typedefs marked with `__attribute__((NSObject))`
-Other pointer types, such as ``int*`` and ``CFStringRef``, are not subject to
+Other pointer types, such as `int*` and `CFStringRef`, are not subject to
ARC's semantics and restrictions.
-.. admonition:: Rationale
-
- We are not at liberty to require all code to be recompiled with ARC;
- therefore, ARC must interoperate with Objective-C code which manages retains
- and releases manually. In general, there are three requirements in order for
- a compiler-supported reference-count system to provide reliable
- interoperation:
-
- * The type system must reliably identify which objects are to be managed. An
- ``int*`` might be a pointer to a ``malloc``'ed array, or it might be an
- interior pointer to such an array, or it might point to some field or local
- variable. In contrast, values of the retainable object pointer types are
- never interior.
-
- * The type system must reliably indicate how to manage objects of a type.
- This usually means that the type must imply a procedure for incrementing
- and decrementing retain counts. Supporting single-ownership objects
- requires a lot more explicit mediation in the language.
-
- * There must be reliable conventions for whether and when "ownership" is
- passed between caller and callee, for both arguments and return values.
- Objective-C methods follow such a convention very reliably, at least for
- system libraries on macOS, and functions always pass objects at +0. The
- C-based APIs for Core Foundation objects, on the other hand, have much more
- varied transfer semantics.
-
-The use of ``__attribute__((NSObject))`` typedefs is not recommended. If it's
+:::{admonition} Rationale
+We are not at liberty to require all code to be recompiled with ARC;
+therefore, ARC must interoperate with Objective-C code which manages retains
+and releases manually. In general, there are three requirements in order for
+a compiler-supported reference-count system to provide reliable
+interoperation:
+
+- The type system must reliably identify which objects are to be managed. An
+ `int*` might be a pointer to a `malloc`'ed array, or it might be an
+ interior pointer to such an array, or it might point to some field or local
+ variable. In contrast, values of the retainable object pointer types are
+ never interior.
+- The type system must reliably indicate how to manage objects of a type.
+ This usually means that the type must imply a procedure for incrementing
+ and dec...
[truncated]
``````````
</details>
https://github.com/llvm/llvm-project/pull/214617
More information about the llvm-branch-commits
mailing list