[clang] Proofread *.rst (#168215)

This patch is limited to single-word replacements to fix spelling
and/or grammar to ease the review process.  Punctuation and markdown
fixes are specifically excluded.

clang/docs/AutomaticReferenceCounting.rst

@@ -2318,7 +2318,7 @@ aligned for an object of type ``id``.  The other qualifiers may be used on
 explicitly under-aligned memory.
 
 The runtime tracks ``__weak`` objects which holds non-null values.  It is
-undefined behavior to direct modify a ``__weak`` object which is being tracked
+undefined behavior to directly modify a ``__weak`` object which is being tracked
 by the runtime except through an
 :ref:`objc_storeWeak <arc.runtime.objc_storeWeak>`,
 :ref:`objc_destroyWeak <arc.runtime.objc_destroyWeak>`, or

clang/docs/Block-ABI-Apple.rst

@@ -34,7 +34,7 @@ attempt to use this ABI on systems prior to SnowLeopard is undefined.
 High Level
 ==========
 
-The ABI of ``Blocks`` consist of their layout and the runtime functions required
+The ABI of ``Blocks`` consists of their layout and the runtime functions required
 by the compiler.  A ``Block`` of type ``R (^)(P...)`` consists of a structure of
 the following form:
 

clang/docs/BoundsSafety.rst

@@ -912,7 +912,7 @@ unsafe library by calling ``get_buf()`` which returns ``void
   ``__bidi_indexable`` gets the lower bound same as the pointer value.
 
 * A type conversion may involve both a bitcast and a bounds annotation cast. For
-  example, casting from ``int *__bidi_indexable`` to ``char *__single`` involve
+  example, casting from ``int *__bidi_indexable`` to ``char *__single`` involves
   a bitcast (``int *`` to ``char *``) and a bounds annotation cast
   (``__bidi_indexable`` to ``__single``). In this case, the compiler performs
   the bitcast and then converts the bounds annotation. This means, ``int
@@ -994,7 +994,7 @@ other types of safety violations such as type confusion. For instance,
 
 ``-fbounds-safety`` heavily relies on run-time checks to keep the bounds safety
 and the soundness of the type system. This may incur significant code size
-overhead in unoptimized builds and leaving some of the adoption mistakes to be
+overhead in unoptimized builds and leave some of the adoption mistakes to be
 caught only at run time. This is not a fundamental limitation, however, because
 incrementally adding necessary static analysis will allow us to catch issues
 early on and remove unnecessary bounds checks in unoptimized builds.

clang/docs/BoundsSafetyAdoptionGuide.rst

@@ -45,7 +45,7 @@ that automatically carries the bounds information.
 Address compiler diagnostics
 ============================
 
-Once you pass ``-fbounds-safety`` to compiler a C file, you will see some new
+Once you pass ``-fbounds-safety`` to compile a C file, you will see some new
 compiler warnings and errors, which guide adoption of ``-fbounds-safety``.
 Consider the following example:
 

clang/docs/CXXTypeAwareAllocators.rst

@@ -90,7 +90,7 @@ Operator selection then proceeds according to the usual rules for choosing
 the best/most constrained match.
 
 Any declaration of a type aware operator new or operator delete must include a
-matching complimentary operator defined in the same scope.
+matching complementary operator defined in the same scope.
 
 Notes
 =====

clang/docs/ClangTools.rst

@@ -72,7 +72,7 @@ instructions on how to setup and use `clang-check`.
 ----------------
 
 Clang-format is both a :doc:`library <LibFormat>` and a :doc:`stand-alone tool
-<ClangFormat>` with the goal of automatically reformatting C++ sources files
+<ClangFormat>` with the goal of automatically reformatting C++ source files
 according to configurable style guides.  To do so, clang-format uses Clang's
 ``Lexer`` to transform an input file into a token stream and then changes all
 the whitespace around those tokens.  The goal is for clang-format to serve both

clang/docs/ClangTransformerTutorial.rst

@@ -78,7 +78,7 @@ can express this a Transformer rewrite rule:
 arguments: the pattern, the edit, and (optionally) an explanatory note. In our
 example, the pattern (``functionDecl(...)``) identifies the declaration of the
 function ``MkX``. Since we're just diagnosing the problem, but not suggesting a
-fix, our edit is an no-op. But, it contains an *anchor* for the diagnostic
+fix, our edit is a no-op. But, it contains an *anchor* for the diagnostic
 message: ``node("fun")`` says to associate the message with the source range of
 the AST node bound to "fun"; in this case, the ill-named function declaration.
 Finally, we use ``cat`` to build a message that explains the change. Regarding the

clang/docs/DataFlowSanitizerDesign.rst

@@ -160,8 +160,8 @@ instructions, glibc memcpy and memmove. When ``-dfsan-track-origins`` is 2, a
 new chain is also appended at loads.
 
 Other instructions do not create new chains, but simply propagate origin trace
-IDs. If an instruction has more than one operands with non-zero labels, the origin
-treace ID of the last operand with non-zero label is propagated to the result of
+IDs. If an instruction has more than one operand with non-zero labels, the origin
+trace ID of the last operand with non-zero label is propagated to the result of
 the instruction.
 
 Memory layout and label management

clang/docs/InternalsManual.rst

@@ -2351,7 +2351,7 @@ different "from" contexts; in this case, they have to share the associated
 errors of the "to" context.
 
 When an error happens, that propagates through the call stack, through all the
-dependant nodes. However, in case of dependency cycles, this is not enough,
+dependent nodes. However, in case of dependency cycles, this is not enough,
 because we strive to mark the erroneous nodes so clients can act upon. In those
 cases, we have to keep track of the errors for those nodes which are
 intermediate nodes of a cycle.

clang/docs/JSONCompilationDatabase.rst

@@ -48,7 +48,7 @@ techniques.
 
 Clang's tooling interface supports reading compilation databases; see
 the :doc:`LibTooling documentation <LibTooling>`. libclang and its
-python bindings also support this (since clang 3.2); see
+Python bindings also support this (since clang 3.2); see
 `CXCompilationDatabase.h </doxygen/group__COMPILATIONDB.html>`_.
 
 Format

clang/docs/LibASTImporter.rst

@@ -502,7 +502,7 @@ The ``-ast-merge <pch-file>`` command-line switch can be used to merge from the
 This file represents the source context.
 When this switch is present then each top-level AST node of the source context is being merged into the destination context.
 If the merge was successful then ``ASTConsumer::HandleTopLevelDecl`` is called for the Decl.
-This results that we can execute the original front-end action on the extended AST.
+This means that we can execute the original front-end action on the extended AST.
 
 Example for C
 ^^^^^^^^^^^^^

clang/docs/MisExpect.rst

@@ -19,7 +19,7 @@ MisExpect diagnostics are intended to help developers identify and address
 these situations, by comparing the branch weights added by the ``llvm.expect``
 intrinsic to those collected through profiling. Whenever these values are
 mismatched, a diagnostic is surfaced to the user. Details on how the checks
-operate in the LLVM backed can be found in LLVM's documentation.
+operate in the LLVM backend can be found in LLVM's documentation.
 
 By default MisExpect checking is quite strict, because the use of the
 ``llvm.expect`` intrinsic is designed for specialized cases, where the outcome

clang/docs/PCHInternals.rst

@@ -504,7 +504,7 @@ Name lookup
   based.  This changes the lookup algorithm for the various tables, such as the
   :ref:`identifier table <pchinternals-ident-table>`: the search starts at the
   most-recent precompiled header.  If no entry is found, lookup then proceeds
-  to the identifier table in the precompiled header it depends on, and so one.
+  to the identifier table in the precompiled header it depends on, and so on.
   Once a lookup succeeds, that result is considered definitive, overriding any
   results from earlier precompiled headers.
 

clang/docs/PointerAuthentication.rst

@@ -684,7 +684,7 @@ a null pointer that the language implementation would.
 The code sequence produced for this operation must not be directly attackable.
 However, if the discriminator values are not constant integers, their
 computations may still be attackable.  In the future, Clang should be enhanced
-to guaranteed non-attackability if these expressions are
+to guarantee non-attackability if these expressions are
 :ref:`safely-derived<Safe derivation>`.
 
 ``ptrauth_auth_function``
@@ -1572,7 +1572,7 @@ type, they contain an ``isa`` pointer signed as described
 :ref:`below<Objc isa and super>`.
 
 The invocation pointer in a block is signed with the ``IA`` key using address
-diversity and a constant dicriminator of 0.  Using a uniform discriminator is
+diversity and a constant discriminator of 0.  Using a uniform discriminator is
 seen as a weakness to be potentially improved, but this is tricky due to the
 subtype polymorphism directly permitted for blocks.
 
@@ -1651,7 +1651,7 @@ declaration, which can cause type errors if the address of the ivar is taken:
   }
   @end
 
-To fix such an mismatch the schema macro from `<ptrauth.h>`:
+To fix such a mismatch the schema macro from `<ptrauth.h>`:
 
 .. code-block:: ObjC
 
@@ -1660,7 +1660,7 @@ To fix such an mismatch the schema macro from `<ptrauth.h>`:
   void f(SEL __ptrauth_objc_sel*);
 
 or less safely, and introducing the possibility of an
-:ref:`signing or authentication oracle<Signing oracles>`, an unauthencaticated
+:ref:`signing or authentication oracle<Signing oracles>`, an unauthenticated
 temporary may be used as intermediate storage.
 
 Alternative implementations

clang/docs/RAVFrontendAction.rst

@@ -101,7 +101,7 @@ Accessing the SourceManager and ASTContext
 ==========================================
 
 Some of the information about the AST, like source locations and global
-identifier information, are not stored in the AST nodes themselves, but
+identifier information, is not stored in the AST nodes themselves, but
 in the ASTContext and its associated source manager. To retrieve them we
 need to hand the ASTContext into our RecursiveASTVisitor implementation.
 

clang/docs/RealtimeSanitizer.rst

@@ -187,7 +187,7 @@ A **partial** list of flags RealtimeSanitizer respects:
    * - ``abort_on_error``
      - OS dependent
      - boolean
-     - If true, the tool calls ``abort()`` instead of ``_exit()`` after printing the error report. On some OSes (MacOS, for example) this is beneficial because a better stack trace is emitted on crash.
+     - If true, the tool calls ``abort()`` instead of ``_exit()`` after printing the error report. On some OSes (macOS, for example) this is beneficial because a better stack trace is emitted on crash.
    * - ``symbolize``
      - ``true``
      - boolean

clang/docs/SafeStack.rst

@@ -73,7 +73,7 @@ are always accessed in a safe way by separating them in a dedicated safe stack
 region. The safe stack is automatically protected against stack-based buffer
 overflows, since it is disjoint from the unsafe stack in memory, and it itself
 is always accessed in a safe way. In the current implementation, the safe stack
-is protected against arbitrary memory write vulnerabilities though
+is protected against arbitrary memory write vulnerabilities through
 randomization and information hiding: the safe stack is allocated at a random
 address and the instrumentation ensures that no pointers to the safe stack are
 ever stored outside of the safe stack itself (see limitations below).

clang/docs/UsersManual.rst

@@ -1090,7 +1090,7 @@ Usually, config file options are placed before command-line options, regardless
 of the actual operation to be performed. The exception is being made for the
 options prefixed with the ``$`` character. These will be used only when the linker
 is being invoked, and added after all of the command-line specified linker
-inputs. Here is some example of ``$``-prefixed options:
+inputs. Here is an example of ``$``-prefixed options:
 
 ::