[clang] Fix typos in documentation (#140211)

clang/docs/DebuggingCoroutines.rst

@@ -255,7 +255,7 @@ However, when optimizations are enabled, the printed result changes drastically:
   {__resume_fn = 0x401280 <coro_task(int)>, __destroy_fn = 0x401390 <coro_task(int)>, __promise = {count = 1}, __int_32_0 = 43, __coro_index = 1 '\001'}
 
 Unused values are optimized out, as well as the name of the local variable `a`.
-The only information remained is the value of a 32 bit integer. In this simple
+The only information remained is the value of a 32-bit integer. In this simple
 case, it seems to be pretty clear that `__int_32_0` represents `a`. However, it
 is not true.
 

clang/docs/InternalsManual.rst

@@ -3560,7 +3560,7 @@ For example:
 
   // expected-note {{{evaluates to '{{2, 3, 4}} == {0, 3, 4}'}}}
 
-The intent is to allow the delimeter to be wider than the longest `{` or `}`
+The intent is to allow the delimiter to be wider than the longest `{` or `}`
 brace sequence in the content, so that if your expected text contains `{{{`
 (three braces) it may be delimited with `{{{{` (four braces), and so on.
 

clang/docs/LanguageExtensions.rst

@@ -497,7 +497,7 @@ __const, __const__, __volatile, __volatile__, __restrict, __restrict__
 ----------------------------------------------------------------------
 
 These are alternate spellings for their non-underscore counterparts, but are
-available in all langauge modes.
+available in all language modes.
 
 __decltype
 ----------
@@ -526,7 +526,7 @@ __typeof, __typeof__, __typeof_unqual, __typeof_unqual__
 --------------------------------------------------------
 
 ``__typeof`` and ``__typeof__`` are alternate spellings for ``typeof``, but are
-available in all langauge modes. These spellings result in the operand,
+available in all language modes. These spellings result in the operand,
 retaining all qualifiers.
 
 ``__typeof_unqual`` and ``__typeof_unqual__`` are alternate spellings for the
@@ -2043,7 +2043,7 @@ references can be used instead of numeric references.
   }
 
 
-Constexpr strings in GNU ASM statememts
+Constexpr strings in GNU ASM statements
 =======================================
 
 In C++11 mode (and greater), Clang supports specifying the template,
@@ -4412,7 +4412,7 @@ It is undefined behavior to call this function on an already initialized
 A builtin function for the target-specific ``va_start`` function-like macro,
 available only in C23 and later. The builtin accepts zero or one argument for
 the ellipsis (``...``). If such an argument is provided, it should be the name
-of the parameter preceeding the ellipsis, which is used for compatibility with
+of the parameter preceding the ellipsis, which is used for compatibility with
 C versions before C23. It is an error to provide two or more variadic arguments.
 This function initializes the given ``__builtin_va_list`` object. It is
 undefined behavior to call this function on an already initialized

clang/docs/Modules.rst

@@ -613,10 +613,10 @@ tls
   A specific target feature (e.g., ``sse4``, ``avx``, ``neon``) is available.
 
 *platform/os*
-  A os/platform variant (e.g. ``freebsd``, ``win32``, ``windows``, ``linux``, ``ios``, ``macos``, ``iossimulator``) is available.
+  An os/platform variant (e.g. ``freebsd``, ``win32``, ``windows``, ``linux``, ``ios``, ``macos``, ``iossimulator``) is available.
 
 *environment*
-  A environment variant (e.g. ``gnu``, ``gnueabi``, ``android``, ``msvc``) is available.
+  An environment variant (e.g. ``gnu``, ``gnueabi``, ``android``, ``msvc``) is available.
 
 **Example:** The ``std`` module can be extended to also include C++ and C++11 headers using a *requires-declaration*:
 

clang/docs/PointerAuthentication.rst

@@ -554,7 +554,7 @@ with this idea:
 
 - It's unclear whether this kind of encryption is even possible without
   increasing the storage size of a signed pointer.  If the storage size can be
-  increased, brute-force atacks can be equally well mitigated by simply storing
+  increased, brute-force attacks can be equally well mitigated by simply storing
   a larger signature.
 
 - It would likely be impossible to implement a ``strip`` operation, which might

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 exmple) 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
@@ -279,7 +279,7 @@ In general, ``ScopedDisabler`` should be preferred, as it is the most performant
      - Run-time
      - Stack
      - High
-     - Suppresses any stack trace contaning the specified pattern.
+     - Suppresses any stack trace containing the specified pattern.
     
 
 ``ScopedDisabler``

clang/docs/ReleaseNotes.rst

@@ -487,7 +487,7 @@ Improvements to Clang's diagnostics
 
 - An error is now emitted when a ``musttail`` call is made to a function marked with the ``not_tail_called`` attribute. (#GH133509).
 
-- ``-Whigher-precisision-for-complex-divison`` warns when:
+- ``-Whigher-precision-for-complex-divison`` warns when:
 
   -	The divisor is complex.
   -	When the complex division happens in a higher precision type due to arithmetic promotion.
@@ -627,7 +627,7 @@ Bug Fixes in This Version
 Bug Fixes to Compiler Builtins
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-- The behvaiour of ``__add_pointer`` and ``__remove_pointer`` for Objective-C++'s ``id`` and interfaces has been fixed.
+- The behaviour of ``__add_pointer`` and ``__remove_pointer`` for Objective-C++'s ``id`` and interfaces has been fixed.
 
 - The signature for ``__builtin___clear_cache`` was changed from
   ``void(char *, char *)`` to ``void(void *, void *)`` to match GCC's signature
@@ -702,7 +702,7 @@ Bug Fixes to C++ Support
   not in the last position.
 - Disallow overloading on struct vs class on dependent types, which is IFNDR, as
   this makes the problem diagnosable.
-- Improved preservation of the presence or abscence of typename specifier when
+- Improved preservation of the presence or absence of typename specifier when
   printing types in diagnostics.
 - Clang now correctly parses ``if constexpr`` expressions in immediate function context. (#GH123524)
 - Fixed an assertion failure affecting code that uses C++23 "deducing this". (#GH130272)

clang/docs/StandardCPlusPlusModules.rst

@@ -709,7 +709,7 @@ Before Clang 19, a change in BMI of any (transitive) dependency would cause the
 outputs of the BMI to change. Starting with Clang 19, changes to non-direct
 dependencies should not directly affect the output BMI, unless they affect the
 results of the compilations. We expect that there are many more opportunities
-for this optimization than we currently have realized and would appreaciate 
+for this optimization than we currently have realized and would appreciate
 feedback about missed optimization opportunities. For example,
 
 .. code-block:: c++

clang/docs/UsersManual.rst

@@ -921,7 +921,7 @@ Clang options that don't fit neatly into other categories.
 
   Instruct clang not to emit the signature string for blocks. Disabling the
   string can potentially break existing code that relies on it. Users should
-  carefully consider this possibiilty when using the flag.
+  carefully consider this possibility when using the flag.
 
 .. _configuration-files:
 
@@ -3198,7 +3198,7 @@ indexed format, regardeless whether it is produced by frontend or the IR pass.
 .. option:: -fprofile-continuous
 
   Enables the continuous instrumentation profiling where profile counter updates
-  are continuously synced to a file. This option sets any neccessary modifiers
+  are continuously synced to a file. This option sets any necessary modifiers
   (currently ``%c``) in the default profile filename and passes any necessary
   flags to the middle-end to support this mode. Value profiling is not supported
   in continuous mode.
@@ -3327,7 +3327,7 @@ on the ``-fprofile-generate`` and the ``-fprofile-use`` flags.
  * ``__LLVM_INSTR_PROFILE_USE``: defined when one of
    ``-fprofile-use``/``-fprofile-instr-use`` is in effect.
 
-The two macros can be used to provide more flexibiilty so a user program
+The two macros can be used to provide more flexibility so a user program
 can execute code specifically intended for profile generate or profile use.
 For example, a user program can have special logging during profile generate:
 
@@ -4154,7 +4154,7 @@ There is a set of concrete HW architectures that OpenCL can be compiled for.
 Generic Targets
 ^^^^^^^^^^^^^^^
 
-- A SPIR-V binary can be produced for 32 or 64 bit targets.
+- A SPIR-V binary can be produced for 32- or 64-bit targets.
 
    .. code-block:: console
 

clang/docs/analyzer/checkers.rst

@@ -1460,7 +1460,7 @@ overflow occurs), the checker assumes that the the index (more precisely, the
 memory offeset) is within bounds.
 
 However, if :ref:`optin-taint-GenericTaint` is enabled and the index/offset is
-tainted (i.e. it is influenced by an untrusted souce), then this checker
+tainted (i.e. it is influenced by an untrusted source), then this checker
 reports the potential out of bounds access:
 
 .. code-block:: c
@@ -2710,7 +2710,7 @@ Check for proper uses of CFNumber APIs.
 
  CFNumberRef test(unsigned char x) {
    return CFNumberCreate(0, kCFNumberSInt16Type, &x);
-    // warn: 8 bit integer is used to initialize a 16 bit integer
+    // warn: 8-bit integer is used to initialize a 16-bit integer
  }
 
 .. _osx-coreFoundation-CFRetainRelease:

clang/docs/analyzer/user-docs/Installation.rst

@@ -28,7 +28,7 @@ Packaged builds for other platforms may eventually be provided, but we need volu
 [Legacy] Using Packaged Builds
 ------------------------------
 
-To use the legacy pacakge builds, simply unpack it anywhere. If the build archive has the name **``checker-XXX.tar.bz2``** then the archive will expand to a directory called **``checker-XXX``**. You do not need to place this directory or the contents of this directory in any special place. Uninstalling the analyzer is as simple as deleting this directory.
+To use the legacy package builds, simply unpack it anywhere. If the build archive has the name **``checker-XXX.tar.bz2``** then the archive will expand to a directory called **``checker-XXX``**. You do not need to place this directory or the contents of this directory in any special place. Uninstalling the analyzer is as simple as deleting this directory.
 
 Most of the files in the **``checker-XXX``** directory will be supporting files for the analyzer that you can simply ignore. Most users will only care about two files, which are located at the top of the **``checker-XXX``** directory: