Fix miscellaneous typos (dotnet#62062)

* Fix miscellaneous typos

* Cleanup trailing whitespaces
```sh
# git remote add dotnet https://github.com/dotnet/runtime && git pull --rebase dotnet main

if uname 2>/devnull | grep -q Darwin; then
    space=" "
fi

git show --name-only --pretty="" HEAD...dotnet/main |\
    xargs -I{} sh -c "test -f {} && sed -i$space'' 's/[[:space:]]*$//' {}"
```

Author: am11

.github/ISSUE_TEMPLATE/02_api_proposal.yml

@@ -33,15 +33,15 @@ body:
                 public void Fancy(T item);
             }
         }
-        ```     
+        ```
     validations:
       required: true
   - type: textarea
     id: api-usage
     attributes:
       label: API Usage
       description: |
-        Please provide code examples that highlight how the proposed API additions are meant to be consumed. This will help suggest whether the API has the right shape to be functional, performant and useable.
+        Please provide code examples that highlight how the proposed API additions are meant to be consumed. This will help suggest whether the API has the right shape to be functional, performant and usable.
       placeholder: API usage
       value: |
         ```C#
@@ -52,7 +52,7 @@ body:
         // Getting the values out
         foreach (var v in c)
             Console.WriteLine(v);
-        ```     
+        ```
     validations:
       required: true
   - type: textarea

docs/design/coreclr/botr/vectors-and-intrinsics.md

@@ -16,7 +16,7 @@ Most hardware intrinsics support is tied to the use of various Vector apis. Ther
 - The fixed length float vectors. `Vector2`, `Vector3`, and `Vector4`. These vector types represent a struct of floats of various lengths. For type layout, ABI and, interop purposes they are represented in exactly the same way as a structure with an appropriate number of floats in it. Operations on these vector types are supported on all architectures and platforms, although some architectures may optimize various operations.
 - The variable length `Vector<T>`. This represents vector data of runtime-determined length. In any given process the length of a `Vector<T>` is the same in all methods, but this length may differ between various machines or environment variable settings read at startup of the process. The `T` type variable may be the following types (`System.Byte`, `System.SByte`, `System.Int16`, `System.UInt16`, `System.Int32`, `System.UInt32`, `System.Int64`, `System.UInt64`, `System.Single`, and `System.Double`), and allows use of integer or double data within a vector. The length and alignment of `Vector<T>` is unknown to the developer at compile time (although discoverable at runtime by using the `Vector<T>.Count` api), and `Vector<T>` may not exist in any interop signature. Operations on these vector types are supported on all architectures and platforms, although some architectures may optimize various operations if the `Vector<T>.IsHardwareAccelerated` api returns true.
 - `Vector64<T>`, `Vector128<T>`, and `Vector256<T>` represent fixed-sized vectors that closely resemble the fixed- sized vectors available in C++. These structures can be used in any code that runs, but very few features are supported directly on these types other than creation. They are used primarily in the processor specific hardware intrinsics apis.
-- Processor specific hardware intrinsics apis such as `System.Runtime.Intrinsics.X86.Ssse3`. These apis map directly to individual instructions or short instruction sequences that are specific to a particular hardware instruction. These apis are only useable on hardware that supports the particular instruction. See https://github.com/dotnet/designs/blob/master/accepted/2018/platform-intrinsics.md for the design of these.
+- Processor specific hardware intrinsics apis such as `System.Runtime.Intrinsics.X86.Ssse3`. These apis map directly to individual instructions or short instruction sequences that are specific to a particular hardware instruction. These apis are only usable on hardware that supports the particular instruction. See https://github.com/dotnet/designs/blob/master/accepted/2018/platform-intrinsics.md for the design of these.
 
 # How to use intrinsics apis
 
@@ -185,7 +185,7 @@ Since System.Private.CoreLib.dll is known to be code reviewed with the code revi
 
 The JIT receives flags which instruct it on what instruction sets are valid to use, and has access to a new jit interface api `notifyInstructionSetUsage(isa, bool supportBehaviorRequired)`.
 
-The notifyInstructionSetUsage api is used to notify the AOT compiler infrastructure that the code may only execute if the runtime environment of the code is exactly the same as the boolean parameter indicates it should be. For instance, if `notifyInstructionSetUsage(Avx, false)` is used, then the code generated must not be used if the `Avx` instruction set is useable. Similarly `notifyInstructionSetUsage(Avx, true)` will indicate that the code may only be used if the `Avx` instruction set is available.
+The notifyInstructionSetUsage api is used to notify the AOT compiler infrastructure that the code may only execute if the runtime environment of the code is exactly the same as the boolean parameter indicates it should be. For instance, if `notifyInstructionSetUsage(Avx, false)` is used, then the code generated must not be used if the `Avx` instruction set is usable. Similarly `notifyInstructionSetUsage(Avx, true)` will indicate that the code may only be used if the `Avx` instruction set is available.
 
 While the above api exists, it is not expected that general purpose code within the JIT will use it. In general jitted code is expected to use a number of different apis to understand the available hardware instruction support available.
 

docs/design/features/arm64-intrinsics.md

@@ -173,7 +173,7 @@ It is also worth noting `System.Runtime.Intrinsics.X86` naming conventions will
 operations which take vector argument(s), but contain an implicit cast(s) to the base type and therefore operate only
 on the first item of the argument vector(s).
 
-### Intinsic Method Argument and Return Types
+### Intrinsic Method Argument and Return Types
 
 Intrinsic methods will typically use a standard set of argument and return types:
 

docs/design/libraries/DllImportGenerator/StructMarshalling.md

@@ -117,7 +117,7 @@ There are 2 usage mechanisms of these attributes.
 
 #### Usage 1, Source-generated interop
 
-The user can apply the `GeneratedMarshallingAttribute` to their structure `S`. The source generator will determine if the type is blittable. If it is blittable, the source generator will generate a partial definition and apply the `BlittableTypeAttribute` to the struct type `S`. Otherwise, it will generate a blittable representation of the struct with the aformentioned requried shape and apply the `NativeMarshallingAttribute` and point it to the blittable representation. The blittable representation can either be generated as a separate top-level type or as a nested type on `S`.
+The user can apply the `GeneratedMarshallingAttribute` to their structure `S`. The source generator will determine if the type is blittable. If it is blittable, the source generator will generate a partial definition and apply the `BlittableTypeAttribute` to the struct type `S`. Otherwise, it will generate a blittable representation of the struct with the aformentioned required shape and apply the `NativeMarshallingAttribute` and point it to the blittable representation. The blittable representation can either be generated as a separate top-level type or as a nested type on `S`.
 
 #### Usage 2, Manual interop
 

src/coreclr/System.Private.CoreLib/src/System/Attribute.CoreCLR.cs

@@ -34,7 +34,7 @@ private static Attribute[] InternalGetCustomAttributes(PropertyInfo element, Typ
             // create the hashtable that keeps track of inherited types
             Dictionary<Type, AttributeUsageAttribute> types = new Dictionary<Type, AttributeUsageAttribute>(11);
 
-            // create an array list to collect all the requested attibutes
+            // create an array list to collect all the requested attributes
             List<Attribute> attributeList = new List<Attribute>();
             CopyToAttributeList(attributeList, attributes, types);
             do
@@ -137,7 +137,7 @@ private static Attribute[] InternalGetCustomAttributes(EventInfo element, Type t
             }
 
             // create the hashtable that keeps track of inherited types
-            // create an array list to collect all the requested attibutes
+            // create an array list to collect all the requested attributes
             Dictionary<Type, AttributeUsageAttribute> types = new Dictionary<Type, AttributeUsageAttribute>(11);
             List<Attribute> attributeList = new List<Attribute>();
             CopyToAttributeList(attributeList, attributes, types);

src/coreclr/ToolBox/superpmi/superpmi-shared/methodcontextreader.h

@@ -40,7 +40,7 @@ struct MethodContextBuffer
     }
 };
 
-// The pack(4) directive is so that each entry is 12 bytes, intead of 16
+// The pack(4) directive is so that each entry is 12 bytes, instead of 16
 #pragma pack(push)
 #pragma pack(4)
 class MethodContextReader

src/coreclr/debug/daccess/daccess.cpp

@@ -8037,7 +8037,7 @@ bool DacHandleWalker::FetchMoreHandles(HANDLESCANPROC callback)
                 if (hTable)
                 {
                     // Yikes!  The handle table callbacks don't produce the handle type or
-                    // the AppDomain that we need, and it's too difficult to propogate out
+                    // the AppDomain that we need, and it's too difficult to propagate out
                     // these things (especially the type) without worrying about performance
                     // implications for the GC.  Instead we'll have the callback walk each
                     // type individually.  There are only a few handle types, and the handle

src/coreclr/debug/daccess/task.cpp

@@ -2416,7 +2416,7 @@ ClrDataModule::GetFileName(
 
         // Try to get the assembly name through GetPath.
         // If the returned name is empty, then try to get the guessed module assembly name.
-        // The guessed assembly name is propogated from metadata's module name.
+        // The guessed assembly name is propagated from metadata's module name.
         //
         if ((m_module->GetPEAssembly()->GetPath().DacGetUnicode(bufLen, name, &_nameLen) && name[0])||
             (m_module->GetPEAssembly()->GetModuleFileNameHint().DacGetUnicode(bufLen, name, &_nameLen) && name[0]))

src/coreclr/debug/di/dbgtransportpipeline.cpp

@@ -231,7 +231,7 @@ HRESULT DbgTransportPipeline::CreateProcessUnderDebugger(
                                               &m_hProcess);
         if (SUCCEEDED(hr))
         {
-            // Wait for the connection to become useable (or time out).
+            // Wait for the connection to become usable (or time out).
             if (!m_pTransport->WaitForSessionToOpen(10000))
             {
                 hr = CORDBG_E_TIMEOUT;
@@ -298,7 +298,7 @@ HRESULT DbgTransportPipeline::DebugActiveProcess(MachineInfo machineInfo, const
     if (SUCCEEDED(hr))
     {
         // TODO: Pass this timeout as a parameter all the way from debugger
-        // Wait for the connection to become useable (or time out).
+        // Wait for the connection to become usable (or time out).
         if (!m_pTransport->WaitForSessionToOpen(10000))
         {
             hr = CORDBG_E_TIMEOUT;

src/coreclr/debug/di/process.cpp

@@ -4591,7 +4591,7 @@ void CordbProcess::DispatchRCEvent()
 
     CONTRACTL
     {
-        // This is happening on the RCET thread, so there's no place to propogate an error back up.
+        // This is happening on the RCET thread, so there's no place to propagate an error back up.
         NOTHROW;
     }
     CONTRACTL_END;
@@ -4777,7 +4777,7 @@ void CordbProcess::DbgAssertAppDomainDeleted(VMPTR_AppDomain vmAppDomainDeleted)
 //    Errors could occur because:
 //    - the event is corrupted (exceptional case)
 //    - the RS is corrupted / OOM (exceptional case)
-//    Exception errors here will propogate back to the Filter() call, and there's not really anything
+//    Exception errors here will propagate back to the Filter() call, and there's not really anything
 //    a debugger can do about an error here (perhaps report it to the user).
 //    Errors must leave IcorDebug in a consistent state.
 //
@@ -8518,7 +8518,7 @@ void CordbProcess::UnrecoverableError(HRESULT errorHR,
     {
         // @dbgtodo - , shim: Once everything is hoisted, we can remove
         // this code.
-        // In the v3 case, we should never get an unrecoverable error. Instead, the HR should be propogated
+        // In the v3 case, we should never get an unrecoverable error. Instead, the HR should be propagated
         // and returned at the top-level public API.
         _ASSERTE(!"Unrecoverable error dispatched in V3 case.");
     }
@@ -10257,7 +10257,7 @@ void CordbRCEventThread::FlushQueuedEvents(CordbProcess* process)
 {
     CONTRACTL
     {
-        NOTHROW; // This is happening on the RCET thread, so there's no place to propogate an error back up.
+        NOTHROW; // This is happening on the RCET thread, so there's no place to propagate an error back up.
     }
     CONTRACTL_END;
 
@@ -11160,7 +11160,7 @@ void CordbProcess::FilterClrNotification(
             // Case 2: Sync Complete
             //
 
-            HandleSyncCompleteRecieved();
+            HandleSyncCompleteReceived();
         }
         else
         {
@@ -11679,7 +11679,7 @@ bool CordbProcess::IsWin32EventThread()
 //    managed event-queue, and coordinating with the dispatch thread (RCET).
 //
 //    @dbgtodo - this should eventually get hoisted into the shim.
-void CordbProcess::HandleSyncCompleteRecieved()
+void CordbProcess::HandleSyncCompleteReceived()
 {
     _ASSERTE(ThreadHoldsProcessLock());
 
@@ -11847,7 +11847,7 @@ Reaction CordbProcess::TriageSyncComplete()
     // we should put that to good use here.
     this->SuspendUnmanagedThreads();
 
-    this->HandleSyncCompleteRecieved();
+    this->HandleSyncCompleteReceived();
 
     // Let the process run free.
     return REACTION(cIgnore);
@@ -12831,7 +12831,7 @@ void CordbProcess::HandleDebugEventForInteropDebugging(const DEBUG_EVENT * pEven
     CordbWin32EventThread * pW32EventThread = this->m_pShim->GetWin32EventThread();
     _ASSERTE(pW32EventThread != NULL);
 
-    // if we were waiting for a retriggered exception but recieved any other event then turn
+    // if we were waiting for a retriggered exception but received any other event then turn
     // off the single stepping and dequeue the IB event. Right now we only use the SS flag internally
     // for stepping during possible retrigger.
     if(reaction.GetType() != Reaction::cInbandExceptionRetrigger && pUnmanagedThread->IsSSFlagNeeded())