Fix typos (dotnet#72709)

docs/coding-guidelines/mono-code-guide.md

@@ -53,7 +53,7 @@ Macros generally use a `MONO_` prefix.  Macros in public API headers *must* use
 
 Prefer the standard C sized types `int32_t`, `intptr_t`, etc over the eglib types `gint32`, `gsize` etc.
 
-One exception is `gboolean` is prefered over C `bool`.
+One exception is `gboolean` is preferred over C `bool`.
 
 There are actually three boolean types to keep in mind:
 

docs/design/coreclr/botr/clr-abi.md

@@ -1,6 +1,6 @@
 # CLR ABI
 
-This document describes the .NET Common Language Runtime (CLR) software conventions (or ABI, "Application Binary Interface"). It focusses on the ABI for the x64 (aka, AMD64), ARM (aka, ARM32 or Thumb-2), and ARM64 processor architectures. Documentation for the x86 ABI is somewhat scant, but information on the basics of the calling convention is included at the bottom of this document.
+This document describes the .NET Common Language Runtime (CLR) software conventions (or ABI, "Application Binary Interface"). It focuses on the ABI for the x64 (aka, AMD64), ARM (aka, ARM32 or Thumb-2), and ARM64 processor architectures. Documentation for the x86 ABI is somewhat scant, but information on the basics of the calling convention is included at the bottom of this document.
 
 It describes requirements that the Just-In-Time (JIT) compiler imposes on the VM and vice-versa.
 
@@ -153,7 +153,7 @@ The below is performed when the GC transition is not suppressed.
 2. For JIT64/AMD64 only: Next for non-IL stubs, the InlinedCallFrame is 'pushed' by setting `Thread->m_pFrame` to point to the InlinedCallFrame (recall that the per-frame initialization already set `InlinedCallFrame->m_pNext` to point to the previous top). For IL stubs this step is accomplished in the per-frame initialization.
 3. The Frame is made active by setting `InlinedCallFrame->m_pCallerReturnAddress`.
 4. The code then toggles the GC mode by setting `Thread->m_fPreemptiveGCDisabled = 0`.
-5. Starting now, no GC pointers may be live in registers. RyuJit LSRA meets this requirement by adding special refPositon `RefTypeKillGCRefs` before unmanaged calls and special helpers.
+5. Starting now, no GC pointers may be live in registers. RyuJit LSRA meets this requirement by adding special refPosition `RefTypeKillGCRefs` before unmanaged calls and special helpers.
 6. Then comes the actual call/PInvoke.
 7. The GC mode is set back by setting `Thread->m_fPreemptiveGCDisabled = 1`.
 8. Then we check to see if `g_TrapReturningThreads` is set (non-zero). If it is, we call `CORINFO_HELP_STOP_FOR_GC`.

docs/design/coreclr/botr/dac-notes.md

@@ -178,7 +178,7 @@ Both methodCold and methodCode are declared as `BYTE *`, but in fact hold target
 
 If this code seems overly complex and confusing to you, that's good. In fact it is. Worse, it provides no protection for the separation of host and target addresses. From the declarations of `methodCold` and `methodCode`, there is no particular reason to interpret them as target addresses at all. If these pointers were dereferenced in DAC builds as if they really were host pointers, the process would probably AV. This snippet demonstrates that any arbitrary pointer type (as opposed to a `PTR` type) can be casted to a `TADDR`. Given that these two variables always hold target addresses, they should be of type `PTR_BYTE`, rather than `BYTE *`.
 
-There is also a disciplined means to cast between different `PTR` types: `dac_cast`. The `dac_cast` operator is the DAC-aware vesion of the C++ `static_cast` operator (which the CLR coding conventions stipulate instead of C-style casts when casting pointer types). The `dac_cast` operator will do any of the following things:
+There is also a disciplined means to cast between different `PTR` types: `dac_cast`. The `dac_cast` operator is the DAC-aware version of the C++ `static_cast` operator (which the CLR coding conventions stipulate instead of C-style casts when casting pointer types). The `dac_cast` operator will do any of the following things:
 
 1. Create a `PTR` type from a `TADDR`
 2. Convert one `PTR` type to another

docs/design/coreclr/botr/exceptions.md

@@ -262,7 +262,7 @@ When a C++ exception is thrown, and there is a missing UACH, the typical failure
 Runtime code into managed code
 ------------------------------
 
-The transition from the runtime into managed code has highly platform-dependent requirements. On 32-bit Windows platforms, the CLR's managed exception code requires that "COMPlusFrameHandler" is installed just before entering managed code. These transitions are handled by highly specialized helper functions, which take care of the appropriate exception handlers. It is very unlikely that any typical new calls into managed would use any other way in. In the event that the COMPlusFrameHander were missing, the most likely effect would be that exception handling code in the target managed code simply wouldn't be executed – no finally blocks, and no catch blocks.
+The transition from the runtime into managed code has highly platform-dependent requirements. On 32-bit Windows platforms, the CLR's managed exception code requires that "COMPlusFrameHandler" is installed just before entering managed code. These transitions are handled by highly specialized helper functions, which take care of the appropriate exception handlers. It is very unlikely that any typical new calls into managed would use any other way in. In the event that the COMPlusFrameHandler were missing, the most likely effect would be that exception handling code in the target managed code simply wouldn't be executed – no finally blocks, and no catch blocks.
 
 Runtime code into external native code
 --------------------------------------

docs/design/coreclr/botr/guide-for-porting.md

@@ -46,7 +46,7 @@ The process follows the following strategy
     not maintained as generally working. It is expected that the interpreter
     will take 1-2 months to enable for an engineer familiar with the CoreCLR
     codebase. A functional interpreter allows the porting team to have a set of
-    engineers which focus exclusively on the JIT and a set which focusses on the
+    engineers which focus exclusively on the JIT and a set which focuses on the
     VM portion of the runtime.
 
 -   Build up a set of scripts that will run the coreclr tests. The normal
@@ -311,7 +311,7 @@ must implement.
     components. The implementation made architecture specific via a long series of
     C preprocessor macros.
 
-6. `gcinfodecoder.h` The GC info format is archictecture specific as it holds
+6. `gcinfodecoder.h` The GC info format is architecture specific as it holds
    information about which specific registers hold GC data. The implementation
    is generally simplified to be defined in terms of register numbers, but if
    the architecture has more registers available for use than existing architectures
@@ -378,7 +378,7 @@ Here is an annotated list of the stubs implemented for Unix on Arm64.
 
     9.  `TheUMEntryPrestub`/ `UMThunkStub` - used to enter the runtime from
         non-managed code through entrypoints generated from the
-        Marshal.GetFunctionPointerForDelagate api.
+        Marshal.GetFunctionPointerForDelegate api.
 
     10. `OnHijackTripThread` - needed for thread suspension to support GC + other
         suspension requiring events. This is typically not needed for very early

docs/design/coreclr/botr/managed-type-system.md

@@ -112,4 +112,4 @@ The type system implementation is found in:
 
 ## Notable differences from CoreCLR type system
 
-* `MethodDesc` has exact generic instantations where possible in managed type system. The code sharing policy in managed type system is one of the pluggable algorithms and it does not affect `MethodDesc` identity. The code sharing policy in the CoreCLR type system is coupled with `MethodDesc` identity. See https://github.com/dotnet/runtime/pull/45744 for an example how this difference manifests itself.
+* `MethodDesc` has exact generic instantiations where possible in managed type system. The code sharing policy in managed type system is one of the pluggable algorithms and it does not affect `MethodDesc` identity. The code sharing policy in the CoreCLR type system is coupled with `MethodDesc` identity. See https://github.com/dotnet/runtime/pull/45744 for an example how this difference manifests itself.

docs/design/coreclr/botr/readytorun-format.md

@@ -702,11 +702,11 @@ To see this in action, we can take a look at the following example, with these o
 | R      | 0x1234   |
 | S      | 0x1238   |
 
-Suppose we decided to have only two buckets, then only the least signficant digit will be used to index the table, the whole hash table will look like this:
+Suppose we decided to have only two buckets, then only the least significant digit will be used to index the table, the whole hash table will look like this:
 
 | Part    | Offset | Content  | Meaning                                                                                                                                                                                   |
 |:--------|:-------|:--------:|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Header  | 0      | 0x04     | This is the header, the least signficant bit is `00`, therefore the table cell is just one byte. The most significant six bit represents 1, which means the number of buckets is 2^1 = 2. |
+| Header  | 0      | 0x04     | This is the header, the least significant bit is `00`, therefore the table cell is just one byte. The most significant six bit represents 1, which means the number of buckets is 2^1 = 2. |
 | Table   | 1      | 0x08     | This is the representation of the unsigned integer 4, which correspond to the offset of the bucket correspond to hash code `0`.                                                           |
 | Table   | 2      | 0x14     | This is the representation of the unsigned integer 10, which correspond to the offset of the bucket correspond to hash code `1`.                                                          |
 | Table   | 3      | 0x18     | This is the representation of the unsigned integer 12, which correspond to the offset of the end of the whole hash table.                                                                 |
@@ -835,7 +835,7 @@ enum ReadyToRunHelper
     READYTORUN_HELPER_FltRound                  = 0xE3,
 
 #ifndef _TARGET_X86_
-    // Personality rountines
+    // Personality routines
     READYTORUN_HELPER_PersonalityRoutine        = 0xF0,
     READYTORUN_HELPER_PersonalityRoutineFilterFunclet = 0xF1,
 #endif

docs/design/coreclr/botr/shared-generics.md

@@ -95,7 +95,7 @@ The first N slots in an instantiation of N arguments are always going to be the
 
 For instance, here is an example of the contents of the generic dictionary for our `Method<string>` example:
 
-| `Method<string>'s dicionary` |
+| `Method<string>'s dictionary` |
 |--------------------------|
 | slot[0]: TypeHandle(`string`)      |
 | slot[1]: Total dictionary size  |

docs/design/coreclr/botr/threading.md

@@ -103,9 +103,9 @@ Hijacking for GC suspension is done by Thread::SysSuspendForGC. This method atte
 2. Get the current CONTEXT for the thread, via GetThreadContext. This is an OS concept; CONTEXT represents the current register state of the thread. This allows us to inspect its instruction pointer, and thus determine what type of code it is currently executing.
 3. Check again if the thread is in cooperative mode, as it may have already left cooperative mode before it could be suspended. If so, the thread is in dangerous territory: the thread may be executing arbitrary native code, and must be resumed immediately to avoid deadlocks.
 4. Check if the thread is running managed code. It is possible that it is executing native VM code in cooperative mode (see Synchronization, below), in which case the thread must be immediately resumed as in the previous step.
-5. Now the thread is suspended in managed code. Depending on whether that code is fully- or partially-interruptable, one of the following is performed:
-  * If fully interruptable, it is safe to perform a GC at any point, since the thread is, by definition, at a safe point. It is reasonable to leave the thread suspended at this point (because it's safe) but various historical OS bugs prevent this from working, because the CONTEXT retrieved earlier may be corrupt). Instead, the thread's instruction pointer is overwritten, redirecting it to a stub that will capture a more complete CONTEXT, leave cooperative mode, wait for the GC to complete, reenter cooperative mode, and restore the thread to its previous state.
-  * If partially-interruptable, the thread is, by definition, not at a safe point. However, the caller will be at a safe point (method transition). Using that knowledge, the CLR "hijacks" the top-most stack frame's return address (physically overwrite that location on the stack) with a stub similar to the one used for fully-interruptable code. When the method returns, it will no longer return to its actual caller, but rather to the stub (the method may also perform a GC poll, inserted by the JIT, before that point, which will cause it to leave cooperative mode and undo the hijack).
+5. Now the thread is suspended in managed code. Depending on whether that code is fully- or partially-interruptible, one of the following is performed:
+  * If fully interruptible, it is safe to perform a GC at any point, since the thread is, by definition, at a safe point. It is reasonable to leave the thread suspended at this point (because it's safe) but various historical OS bugs prevent this from working, because the CONTEXT retrieved earlier may be corrupt). Instead, the thread's instruction pointer is overwritten, redirecting it to a stub that will capture a more complete CONTEXT, leave cooperative mode, wait for the GC to complete, reenter cooperative mode, and restore the thread to its previous state.
+  * If partially-interruptible, the thread is, by definition, not at a safe point. However, the caller will be at a safe point (method transition). Using that knowledge, the CLR "hijacks" the top-most stack frame's return address (physically overwrite that location on the stack) with a stub similar to the one used for fully-interruptible code. When the method returns, it will no longer return to its actual caller, but rather to the stub (the method may also perform a GC poll, inserted by the JIT, before that point, which will cause it to leave cooperative mode and undo the hijack).
 
 ThreadAbort / AppDomain-Unload
 ==============================

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

@@ -177,7 +177,7 @@ Code will be compiled using the optimistic instruction set to drive compilation,
 -  Any use of a platform intrinsic in the codebase SHOULD be wrapped with a call to the associated IsSupported property. This wrapping may be done within the same function that uses the hardware intrinsic, but this is not required as long as the programmer can control all entrypoints to a function that uses the hardware intrinsic.
 -  If an application developer is highly concerned about startup performance, developers should avoid use intrinsics beyond Sse42, or should use Crossgen with an updated baseline instruction set support.
 
-### Crossgen2 ajustment to rules for System.Private.CoreLib.dll
+### Crossgen2 adjustment to rules for System.Private.CoreLib.dll
 Since System.Private.CoreLib.dll is known to be code reviewed with the code review rules as written above for crossgen1 with System.Private.CoreLib.dll, it is possible to relax rule "Code which attempts to use instruction sets outside of the optimistic set will generate code that will not be used on machines with support for the instruction set." What this will do is allow the generation of non-optimal code for these situations, but through the magic of code review, the generated logic will still work correctly.
 
 

docs/design/coreclr/jit/eh-writethru.md

@@ -61,8 +61,8 @@ There are a number of wrinkles informing this design based on how the JIT models
 - The jit does not model which handlers are reachable from a given protected region,
   so considers a variable live into a handler if it is live into any handler in the method.
 
-It is posible to do better than the "store every definition" approach outlined
-in the design, but the expectation is that this would require posibly
+It is possible to do better than the "store every definition" approach outlined
+in the design, but the expectation is that this would require possibly
 modifying the model in the JIT and staging more throughput intensive analyses.
 With these considerations this design was selected and further improvements
 left to future optimization.

docs/design/coreclr/jit/finally-optimizations.md

@@ -298,7 +298,7 @@ Empirical studies have shown that most finallys are small. Thus to
 avoid excessive code growth, a crude size estimate is formed by
 counting the number of statements in the blocks that make up the
 finally. Any finally larger that 15 statements is not cloned. In our
-study this disqualifed about 0.5% of all finallys from cloning.
+study this disqualified about 0.5% of all finallys from cloning.
 
 ### EH Nesting Considerations
 
@@ -416,7 +416,7 @@ blocks. Clear the finally target bit and any GT_END_LFIN from the
 continuation.
 
 If all call finallys are converted, modify the region to be try/fault
-(interally EH_HANDLER_FAULT_WAS_FINALLY, so we can distinguish it
+(internally EH_HANDLER_FAULT_WAS_FINALLY, so we can distinguish it
 later from "organic" try/faults).  Otherwise leave it as a
 try/finally.
 

docs/design/coreclr/jit/first-class-structs.md

@@ -222,7 +222,7 @@ This would be done in multiple phases:
       * This work item should address issue [#4323 RyuJIT properly optimizes structs with a single field
         if the field type is int but not if it is double](https://github.com/dotnet/runtime/issues/4323)
         (test is `JIT\Regressions\JitBlue\GitHub_1161`),
-        [#7200 Struct getters are generating unneccessary
+        [#7200 Struct getters are generating unnecessary
         instructions on x64 when struct contains floats](https://github.com/dotnet/runtime/issues/7200)
         and [#11413 Inefficient codegen for casts between same size types](https://github.com/dotnet/runtime/issues/11413).
     * Remove the pessimization in `LocalAddressVisitor::PostOrderVisit()` for the `GT_RETURN` case.
@@ -347,7 +347,7 @@ The following issues illustrate some of the motivation for improving the handlin
   * Unfortunately, there is not currently a scenario or test case for this issue.
 
 * [\#10879 Unix: Unnecessary struct copy while passing struct of size <=16](https://github.com/dotnet/runtime/issues/10879)
-* [\#9839 [RyuJIT] Eliminate unecessary copies when passing structs](https://github.com/dotnet/runtime/issues/9839)
+* [\#9839 [RyuJIT] Eliminate unnecessary copies when passing structs](https://github.com/dotnet/runtime/issues/9839)
   * These require changing both the callsite and the callee to avoid copying the parameter onto the stack.
   * It may be that these have been addressed by [PR #43870](https://github.com/dotnet/runtime/pull/43870).
 

docs/design/coreclr/jit/inline-size-estimates.md

@@ -198,7 +198,7 @@ to be practical.
 Second, even if we could obtain the actual size of prospective inline
 candidates, we might not want to use this data. The final code
 sequence emitted by the compiler depends intimately on details of the
-target architecture, runtime conventions (ABIs), and capabilites of the
+target architecture, runtime conventions (ABIs), and capabilities of the
 compiler phases that run after inlining. If we allow feedback into hey
 heuristics by incorporating data from these "downstream" sources, we
 introduce various forms of coupling that have important

docs/design/coreclr/jit/investigate-stress.md

@@ -28,4 +28,4 @@ Enabling GC Hole Stress causes GCs to always occur in specific locations and tha
 
 **0x1 | 0x2** – 0x3 are "in the VM". Failures in 0x1 or 0x2 can be due to VM-related reasons, like lack of GC reporting/pinning in interop frames.
 
-**0x4 | 0x8** – 0xC runs GC stress for each JIT generated instruction (either dynamically or AOT, in R2R). Failures in 0x4 or 0x8 typically mean a failure in GC info. Only happens once for any instruction, so can miss failures that only occur on non-first GCs. This mode replaces the target instuction with a with breakpoint instruction and that affects disassembly.
+**0x4 | 0x8** – 0xC runs GC stress for each JIT generated instruction (either dynamically or AOT, in R2R). Failures in 0x4 or 0x8 typically mean a failure in GC info. Only happens once for any instruction, so can miss failures that only occur on non-first GCs. This mode replaces the target instruction with a with breakpoint instruction and that affects disassembly.