Typos (#19737)

* testsing -> testing

* reclaming -> reclaiming

* oppurtunity -> opportunity

* implemenation -> implementation

* indicaates -> indicates

* enregisterd -> enregistered

* compuations -> computations

* convinient -> convenient

* intution -> intuition

* Communicaton -> Communication

diff --git a/Documentation/building/windows-instructions.md b/Documentation/building/windows-instructions.md
index 7e9bfef03e60fb773ae11a95eafcd47582901f61..5d1cb1684cac7bdb5727ea7ee5d09d101082e1b5 100644 (file)
--- a/Documentation/building/windows-instructions.md
+++ b/Documentation/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 
 

diff --git a/Documentation/design-docs/assemblyloadcontext.md b/Documentation/design-docs/assemblyloadcontext.md
index 6da430703c6bbbbe7789632fa2c9b090efd305c4..b88851009289e925f2fa34d8ab66d1c4261802a3 100644 (file)
--- a/Documentation/design-docs/assemblyloadcontext.md
+++ b/Documentation/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
 

diff --git a/Documentation/design-docs/eh-writethru.md b/Documentation/design-docs/eh-writethru.md
index 602ac0ba2344a4f18f9e8b27a9d7645c61bcdb11..ea63b1a575cb83654282d0485035ddf460716e5b 100644 (file)
--- a/Documentation/design-docs/eh-writethru.md
+++ b/Documentation/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

diff --git a/Documentation/design-docs/inline-size-estimates.md b/Documentation/design-docs/inline-size-estimates.md
index b7a2f16bf924448c1f8be5ca14a96e5ade2678ce..4a7915e751d6a1bd33f509a54a7a7dcf5e967634 100644 (file)
--- a/Documentation/design-docs/inline-size-estimates.md
+++ b/Documentation/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
 

diff --git a/Documentation/design-docs/longs-on-32bit-arch.md b/Documentation/design-docs/longs-on-32bit-arch.md
index d04efb59fa3a48707f1d8bb8b457cad7a99753d2..b8eec9f0f7020145e2d532784fbe0da1dec8330b 100644 (file)
--- a/Documentation/design-docs/longs-on-32bit-arch.md
+++ b/Documentation/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.

diff --git a/Documentation/design-docs/standalone-gc-loading.md b/Documentation/design-docs/standalone-gc-loading.md
index 95e89052e22930908c66b8ff8431c7b38dd51183..20999d9ca5eded5cd92862e5a61eff297e6920c4 100644 (file)
--- a/Documentation/design-docs/standalone-gc-loading.md
+++ b/Documentation/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

diff --git a/Documentation/performance/JitOptimizerTodoAssessment.md b/Documentation/performance/JitOptimizerTodoAssessment.md
index 703862a611fa8d2a8c03a214cbd3f70c0858c265..dc08dc8ae16ef98f886509d675053a2fa36aaa03 100644 (file)
--- a/Documentation/performance/JitOptimizerTodoAssessment.md
+++ b/Documentation/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),

diff --git a/Documentation/project-docs/dotnet-filenames.md b/Documentation/project-docs/dotnet-filenames.md
index e12f05b18fe2e6ee2a8913eaa1abf05d3a88b472..7a228d0f968e39a5e7e47621006a215f9b17e8a6 100644 (file)
--- a/Documentation/project-docs/dotnet-filenames.md
+++ b/Documentation/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.

diff --git a/Documentation/project-docs/glossary.md b/Documentation/project-docs/glossary.md
index 41c505079137ac6169ef9c146157b6cc3ede85ad..00a8210bd61e230b2c44b42e885e73674ab28d26 100644 (file)
--- a/Documentation/project-docs/glossary.md
+++ b/Documentation/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. |

diff --git a/README.md b/README.md
index 33140174349dec424ab5f85d31ff89e7140d02ec..fb2aaa7528e9f88756c242956e5fec4cdba0be00 100644 (file)
--- a/README.md
+++ b/README.md
@@ -160,7 +160,7 @@ There are two basic techniques for using your new runtime.
  2. **Use corerun.exe to run an application using unpackaged Dlls**. This repository also defines a simple host called
  corerun.exe that does NOT take any dependency on NuGet.   Basically it has to be told where to get all the
  necessary DLLs you actually use, and you have to gather them together 'by hand'.   This is the technique that
- all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testsing).
+ all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testing).
  See [Using corerun To Run .NET Core Application](Documentation/workflow/UsingCoreRun.md) for details on using 
  this technique.