Typos (dotnet/coreclr#19737)

* testsing -> testing

* reclaming -> reclaiming

* oppurtunity -> opportunity

* implemenation -> implementation

* indicaates -> indicates

* enregisterd -> enregistered

* compuations -> computations

* convinient -> convenient

* intution -> intuition

* Communicaton -> Communication


Commit migrated from dotnet/coreclr@4c7c066

docs/coreclr/building/windows-instructions.md

@@ -75,7 +75,7 @@ any recent (2.4+) version of Python should work, including Python 3.
 
 ## Git
 
-For actual user operations, it is often more convinient to use the GIT features built into Visual Studio 2015.
+For actual user operations, it is often more convenient to use the GIT features built into Visual Studio 2015.
 However the CoreCLR and the tests use the GIT command line utilities directly so you need to install them
 for these to work properly.   You can get it from 
 

docs/coreclr/design-docs/assemblyloadcontext.md

@@ -38,7 +38,7 @@ However, if *C1* was not found in *A1's* context, the *Load* method override in
 
 If the *Load* method override does not resolve the load, fallback to *Default LoadContext* is attempted to resolve the load incase the assembly was already loaded there. If the operating context is *Default LoadContext*, there is no fallback attempted since it has nothing to fallback to.
 
-If the *Default LoadContext* fallback also did not resolve the load (or was not applicable), the *Resolving* event is invoked against *A1's* load context. This is the last oppurtunity to attempt to resolve the assembly load. If there are no subscribers for this event, or neither resolved the load, a *FileNotFoundException* is thrown.
+If the *Default LoadContext* fallback also did not resolve the load (or was not applicable), the *Resolving* event is invoked against *A1's* load context. This is the last opportunity to attempt to resolve the assembly load. If there are no subscribers for this event, or neither resolved the load, a *FileNotFoundException* is thrown.
 
 ## PInvoke Resolution
 
@@ -72,7 +72,7 @@ This method can be used to load an assembly into a load context different from t
 
 ### Resolving
 
-This event is raised to give the last oppurtunity to a *LoadContext* instance to attempt to resolve a requested assembly that has neither been resolved by **Load** method, nor by fallback to **Default LoadContext**.
+This event is raised to give the last opportunity to a *LoadContext* instance to attempt to resolve a requested assembly that has neither been resolved by **Load** method, nor by fallback to **Default LoadContext**.
 
 ## Assembly Load APIs and LoadContext
 

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

@@ -88,7 +88,7 @@ the more expensive analysis out of the startup path.
 On the IR directly before SSA build:
 - Run global liveness to identify local vars that cross EH boundaries (as a
   byproduct of this these local vars are marked "do not enregister")
-- Foreach EH local var create a new local var "proxy" that can be enregisterd.
+- Foreach EH local var create a new local var "proxy" that can be enregistered.
 - Iterate each block in the flow graph doing the following:
   * Foreach tree in block do a post order traversal and
     - Replace all appearances of EH local vars with the defined proxy

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

@@ -233,7 +233,7 @@ caller, callee, and the capabilities of the compiler?
 The tried-and-true approach is to build the heuristic manually. There
 are two prongs to the approach: the first is case analysis of actual
 behavior, and the second is modelling based on the compiler writer's
-experience and intution.
+experience and intuition.
 
 ### Some Case Analysis
 

docs/coreclr/design-docs/longs-on-32bit-arch.md

@@ -43,7 +43,7 @@ the lo and hi computations together.
 There are concerns about this, because it requires generating a number of extra temps
 in the case of nested expressions. However, mikedn has done some experimentation
 [here](https://github.com/mikedn/coreclr/blob/decompose/src/jit/lower.cpp#L424) 
-that indicaates that this approach may not be as problematic as we feared.
+that indicates that this approach may not be as problematic as we feared.
 
 This basic idea is that whenever we need to decompose hi/lo operations but keep them
 together (i.e. can’t preserve the tree traversal/linear order invariants), we create a temp.

docs/coreclr/design-docs/standalone-gc-loading.md

@@ -17,7 +17,7 @@ some terms that will be used often in this document.
   of an execution engine varies widely between runtimes; the CoreRT EE is primarily in managed code
   (C#), while CoreCLR (and the .NET Framework)'s EE is primarily in C++.
 * The **GC**, or **Garbage Collector** - The component of the CLR responsible for allocating managed
-  objects and reclaming unused memory. It is written in C++ and the code is shared by multiple runtimes.
+  objects and reclaiming unused memory. It is written in C++ and the code is shared by multiple runtimes.
   (That is, CoreCLR/CoreRT may have different execution engines, but they share the *same* GC code.)
 * The **DAC**, or **Data Access Component** - A subset of the execution engine that is compiled in
   such a way that it can be run *out of process*, when debugging .NET code using a debugger. The DAC

docs/coreclr/performance/JitOptimizerTodoAssessment.md

@@ -69,7 +69,7 @@ high priority.
 
 ### Loop Optimizations
 
-We haven't been targeting benchmarks that spend a lot of time doing compuations
+We haven't been targeting benchmarks that spend a lot of time doing computations
 in an inner loop.  Pursuing loop optimizations for the peanut butter effect
 would seem odd.  So this simply hasn't bubbled up in priority yet, though it's
 bound to eventually.  Obvious candidates include [IV widening](https://github.com/dotnet/coreclr/issues/9179),

docs/coreclr/project-docs/dotnet-filenames.md

@@ -4,7 +4,7 @@
 .NET has had many mysterious filenames over time. This document defines their purpose.
 
 - coreclr.dll: The implementation of CoreCLR.
-- clr.dll: The implemenation of the .NET Framework CLR since the .NET Framework 4.
+- clr.dll: The implementation of the .NET Framework CLR since the .NET Framework 4.
 - mscorwks.dll: The .NET Framework CLR implementation up until version 2/3.5. It was called "wks" (pronounced "works") because it originally contained the client or "workstation" GC. Up until the .NET Framework 2, there was another variant of the CLR that contained the "server" GC, called mscorsvr.dll. In the .NET Framework 2 release, the workstation and server GC were merged together in a single implementation, in mscorwks.dll, while mscorsvr.dll was deprecated.
 - mscorsvr.dll: See mscorwks.dll.
 - mscordacwks: A variant of mscorwks.dll (for the .NET Framework CLR), used only/primarily while debugging. It contains the "DAC" version of the VM implementation.

docs/coreclr/project-docs/glossary.md

@@ -16,7 +16,7 @@ As much as possible, we should link to the most authoritative and recent source
 | DAC | Data Access Component. An abstraction layer over the internal structures in the runtime. |
 | EE | Execution Engine. |
 | GC | [Garbage Collector](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/garbage-collection.md). |
-| IPC | Inter-Process Communicaton. |
+| IPC | Inter-Process Communication. |
 | JIT | [Just-in-Time](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/ryujit-overview.md) compiler. RyuJIT is the code name for the next generation Just-in-Time(aka "JIT") for the .NET runtime. |
 | LCG | Lightweight Code Generation. An early name for [dynamic methods](https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/src/System/Reflection/Emit/DynamicMethod.cs). |
 | MD | MetaData. |