Skip to content

Conversation

kazutakahirata
Copy link
Contributor

No description provided.

@llvmbot llvmbot added the clang Clang issues not falling into any other category label Aug 23, 2025
@llvmbot
Copy link
Member

llvmbot commented Aug 23, 2025

@llvm/pr-subscribers-clang

Author: Kazu Hirata (kazutakahirata)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/155071.diff

1 Files Affected:

  • (modified) clang/docs/AutomaticReferenceCounting.rst (+6-6)
diff --git a/clang/docs/AutomaticReferenceCounting.rst b/clang/docs/AutomaticReferenceCounting.rst
index bcac73215c9d3..80bbd25121148 100644
--- a/clang/docs/AutomaticReferenceCounting.rst
+++ b/clang/docs/AutomaticReferenceCounting.rst
@@ -740,7 +740,7 @@ following rules apply:
 
 * If the qualifier is so applied at a position in the declaration
   where the next-innermost declarator is a function declarator, and
-  there is an block declarator within that function declarator, then
+  there is a block declarator within that function declarator, then
   the qualifier applies instead to that block declarator and this rule
   is considered afresh beginning from the new position.
 
@@ -924,7 +924,7 @@ not support ``__weak`` references.
 
 A class may indicate that it does not support weak references by providing the
 ``objc_arc_weak_reference_unavailable`` attribute on the class's interface declaration.  A
-retainable object pointer type is **weak-unavailable** if
+retainable object pointer type is **weak-unavailable** if it
 is a pointer to an (optionally protocol-qualified) Objective-C class ``T`` where
 ``T`` or one of its superclasses has the ``objc_arc_weak_reference_unavailable``
 attribute.  A program is ill-formed if it applies the ``__weak`` ownership
@@ -1129,7 +1129,7 @@ be the same for identical code.
   C and C++ while still automatically managing memory.  While it is
   usually simpler and more idiomatic to use Objective-C objects for
   secondary data structures, doing so can introduce extra allocation
-  and message-send overhead, which can cause to unacceptable
+  and message-send overhead, which can cause unacceptable
   performance.  Using structs can resolve some of this tension.
 
   ``__autoreleasing`` is forbidden because it is treacherous to rely
@@ -1446,7 +1446,7 @@ ill-formed.
 Template arguments
 ^^^^^^^^^^^^^^^^^^
 
-If a template argument for a template type parameter is an retainable object
+If a template argument for a template type parameter is a retainable object
 owner type that does not have an explicit ownership qualifier, it is adjusted
 to have ``__strong`` qualification.  This adjustment occurs regardless of
 whether the template argument was deduced or explicitly specified.
@@ -2064,7 +2064,7 @@ You can test if your compiler has support for ``objc_externally_retained`` with
 ``self``
 --------
 
-The ``self`` parameter variable of an non-init Objective-C method is considered
+The ``self`` parameter variable of a non-init Objective-C method is considered
 :ref:`externally-retained <arc.misc.externally_retained>` by the implementation.
 It is undefined behavior, or at least dangerous, to cause an object to be
 deallocated during a message send to that object.  In an init method, ``self``
@@ -2334,7 +2334,7 @@ emit, which are described in the remainder of this section.
 
   * the machine code to do so is significantly smaller,
   * it is much easier to recognize the C functions in the ARC optimizer, and
-  * a sufficient sophisticated runtime may be able to avoid the message send in
+  * a sufficiently sophisticated runtime may be able to avoid the message send in
     common cases.
 
   Several other of these functions are "fused" operations which can be

@kazutakahirata kazutakahirata merged commit 4b23606 into llvm:main Aug 23, 2025
12 checks passed
@kazutakahirata kazutakahirata deleted the cleanup_20250822_proofread_clang_ARC branch August 23, 2025 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants