Fix some typos (NFC) (#133558)

Author: qinkunbao

clang/docs/BoundsSafety.rst

@@ -227,7 +227,7 @@ meaning they do not have ABI implications.
   annotated with ``__ended_by(Q)``. In this case, the end of the range extends
   to the pointer ``Q``. This is used for "iterator" support in C where you're
   iterating from one pointer value to another until a final pointer value is
-  reached (and the final pointer value is not dereferencable).
+  reached (and the final pointer value is not dereferenceable).
 
 Accessing a pointer outside the specified bounds causes a run-time trap or a
 compile-time error. Also, the model maintains correctness of bounds annotations
@@ -507,7 +507,7 @@ Default pointer types in ``typeof()``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When ``typeof()`` takes an expression, it respects the bounds annotation on
-the expression type, including the bounds annotation is implcit. For example,
+the expression type, including the bounds annotation is implicit. For example,
 the global variable ``g`` in the following code is implicitly ``__single`` so
 ``typeof(g)`` gets ``char *__single``. The similar is true for the parameter
 ``p``, so ``typeof(p)`` returns ``void *__single``. The local variable ``l`` is

clang/docs/ConstantInterpreter.rst

@@ -293,4 +293,4 @@ TypeInfoPointer
 
 ``TypeInfoPointer`` tracks two types: the type assigned to
 ``std::type_info`` and the type which was passed to ``typeinfo``.
-It is part of the taged union in ``Pointer``.
+It is part of the tagged union in ``Pointer``.

clang/docs/HIPSupport.rst

@@ -704,7 +704,7 @@ Open Questions / Future Developments
 SPIR-V Support on HIPAMD ToolChain
 ==================================
 
-The HIPAMD ToolChain supports targetting
+The HIPAMD ToolChain supports targeting
 `AMDGCN Flavoured SPIR-V <https://llvm.org/docs/SPIRVUsage.html#target-triples>`_.
 The support for SPIR-V in the ROCm and HIPAMD ToolChain is under active
 development.

clang/docs/HLSL/AvailabilityDiagnostics.rst

@@ -48,7 +48,7 @@ Strict Diagnostic Mode
 
 When strict HLSL availability diagnostic mode is enabled the compiler must report all HLSL API availability issues regardless of code reachability. The implementation of this mode takes advantage of an existing diagnostic scan in ``DiagnoseUnguardedAvailability`` class which is already traversing AST of each function as soon as the function body has been parsed. For HLSL, this pass was only slightly modified, such as making sure diagnostic messages are in the ``hlsl-availability`` group and that availability checks based on shader stage are not included if the shader stage context is unknown.
 
-If the compilation target is a shader library, only availability based on shader model version can be diagnosed during this scan. To diagnose availability based on shader stage, the compiler needs to run the AST traversals implementated in ``DiagnoseHLSLAvailability`` at the end of the translation unit as described above.
+If the compilation target is a shader library, only availability based on shader model version can be diagnosed during this scan. To diagnose availability based on shader stage, the compiler needs to run the AST traversals implemented in ``DiagnoseHLSLAvailability`` at the end of the translation unit as described above.
 
 As a result, availability based on specific shader stage will only be diagnosed in code that is reachable from a shader entry point or library export function. It also means that function bodies might be scanned multiple time. When that happens, care should be taken not to produce duplicated diagnostics.
 

clang/docs/MSVCCompatibility.rst

@@ -240,7 +240,7 @@ In the above example ``hwPopCnt`` will not be inlined into ``PopCnt`` since ``Po
 With a larger function that does real work the function call overhead is negligible. However in our popcnt example there is the function call
 overhead. There is no analog for this specific MSVC behavior in clang.
 
-For clang we effectively have to create the dispatch function ourselves to each specfic implementation.
+For clang we effectively have to create the dispatch function ourselves to each specific implementation.
 
 SIMD vector types
 =================

clang/docs/SanitizerCoverage.rst

@@ -314,7 +314,7 @@ will not be instrumented.
   void __sanitizer_cov_trace_div4(uint32_t Val);
   void __sanitizer_cov_trace_div8(uint64_t Val);
 
-  // Called before a GetElemementPtr (GEP) instruction
+  // Called before a GetElementPtr (GEP) instruction
   // for every non-constant array index.
   void __sanitizer_cov_trace_gep(uintptr_t Idx);
 

clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp

@@ -167,8 +167,8 @@ class ConstantPropagationAnalysis
                         ? ValueLattice(R.Val.getInt().getExtValue())
                         : ValueLattice::top();
       } else {
-        // An unitialized variable holds *some* value, but we don't know what it
-        // is (it is implementation defined), so we set it to top.
+        // An uninitialized variable holds *some* value, but we don't know what
+        // it is (it is implementation defined), so we set it to top.
         Vars[Var] = ValueLattice::top();
       }
     } else if (Nodes.getNodeAs<clang::Expr>(kJustAssignment)) {

clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

@@ -4888,7 +4888,7 @@ TEST(TransferTest, PointerEquality) {
 
       // We won't duplicate all of the tests above with `!=`, as we know that
       // the implementation simply negates the result of the `==` comparison.
-      // Instaed, just spot-check one case.
+      // Instead, just spot-check one case.
       bool p1_ne_p1 = (p1 != p1);
 
       (void)0; // [[p]]

clang/unittests/StaticAnalyzer/CallEventTest.cpp

@@ -61,7 +61,7 @@ void addCXXDeallocatorChecker(AnalysisASTConsumer &AnalysisConsumer,
 }
 
 // TODO: What we should really be testing here is all the different varieties
-// of delete operators, and wether the retrieval of their arguments works as
+// of delete operators, and whether the retrieval of their arguments works as
 // intended. At the time of writing this file, CXXDeallocatorCall doesn't pick
 // up on much of those due to the AST not containing CXXDeleteExpr for most of
 // the standard/custom deletes.

clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp

@@ -418,8 +418,8 @@ TEST(RegisterDeps, DependencyInteraction) {
 
   // Weak dependencies are registered before strong dependencies. This is most
   // important for purely diagnostic checkers that are implemented as a part of
-  // purely modeling checkers, becuse the checker callback order will have to be
-  // established in between the modeling portion and the weak dependency.
+  // purely modeling checkers, because the checker callback order will have to
+  // be established in between the modeling portion and the weak dependency.
   EXPECT_TRUE(
       runCheckerOnCode<addWeakDepAndStrongDep>("void f() {int i;}", Diags));
   EXPECT_EQ(Diags, "test.RegistrationOrder: test.WeakDep\ntest."

clang/unittests/Tooling/ExecutionTest.cpp

@@ -214,7 +214,7 @@ TEST(StandaloneToolTest, SimpleActionWithResult) {
   auto KVs = Executor.getToolResults()->AllKVResults();
   ASSERT_EQ(KVs.size(), 1u);
   EXPECT_EQ("f", KVs[0].first);
-  // Currently the standlone executor returns empty corpus, revision, and
+  // Currently the standalone executor returns empty corpus, revision, and
   // compilation unit.
   EXPECT_EQ("::/1", KVs[0].second);