Fix typos (dotnet#69537)

* Fix typos

* Fix typo: seperate -> separate

* Rename ApplicationNameSetFromArgument

* Update src/coreclr/vm/methodtablebuilder.cpp

* Update docs/coding-guidelines/clr-code-guide.md

Co-authored-by: Dan Moseley <danmose@microsoft.com>

* Update src/mono/mono/tests/verifier/make_tests.sh

Co-authored-by: Dan Moseley <danmose@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Author: 3 people

Diff for: .devcontainer/Dockerfile

@@ -34,9 +34,9 @@ RUN sudo apt-get install libnss3 -y \
     && apt-get install libgbm-dev -y \
     && apt-get install libpango-1.0-0 -y \
     && apt-get install libcairo2 -y \
-    && apt-get install libasound2 -y 
+    && apt-get install libasound2 -y
 
-#install firefox dependecies to run debugger tests:
+# install firefox dependencies to run debugger tests:
 RUN sudo apt-get install libdbus-glib-1-2 -y \
     && apt-get install libgtk-3-0 -y \
-    && apt-get install libx11-xcb-dev  -y
+    && apt-get install libx11-xcb-dev  -y

Diff for: docs/coding-guidelines/clr-code-guide.md

@@ -912,7 +912,7 @@ It depends.
 
 If you initialize the crst as CRST_HOST_BREAKABLE, any attempt to acquire the lock can trigger an exception (intended to kill your thread to break the deadlock.) Otherwise, you are guaranteed not to get an exception or failure. Regardless of the flag setting, releasing a lock will never fail.
 
-You can only use a non host-breakable lock if you can guarantee that that lock will never participate in a deadlock. If you cannot guarantee this, you must use a host-breakable lock and handle the exception. Otherwise, a CLR host will not be able to break deadlocks cleanly.
+You can only use a non host-breakable lock if you can guarantee that the lock will never participate in a deadlock. If you cannot guarantee this, you must use a host-breakable lock and handle the exception. Otherwise, a CLR host will not be able to break deadlocks cleanly.
 
 There are several ways we enforce this.
 

Diff for: docs/design/coreclr/botr/readytorun-overview.md

@@ -265,7 +265,7 @@ Experiments with disabled cross-module inlining with the selectively enabled inl
 
 ## Non-Virtual calls as the baseline solution to all other versioning issues
 
-It is important to observe that once you have a mechanism for doing non-virtual function calls in a version resilient way (by having an indirect CALL through a slot that that can be fixed lazily at runtime, all other versioning problems _can_ be solved in that way by calling back to the 'definer' module, and having the operation occur there instead. Issues associated with this technique
+It is important to observe that once you have a mechanism for doing non-virtual function calls in a version resilient way (by having an indirect CALL through a slot that can be fixed lazily at runtime, all other versioning problems _can_ be solved in that way by calling back to the 'definer' module, and having the operation occur there instead. Issues associated with this technique
 
 1. You will pay the cost of a true indirection function call and return, as well as any argument setup cost. This cost may be visible in constructs that do not contain a call naturally, like fetching string literals or other constants. You may be able to get better performance from another technique (for example, we did so with instance field access).
 2. It introduces a lot of indirect calls. It is not friendly to systems that disallow on the fly code generation. A small helper stub has to be created at runtime in the most straightforward implementation, or there has to be a scheme how to pre-create or recycle the stubs.

Diff for: docs/design/coreclr/botr/xplat-minidump-generation.md

@@ -4,7 +4,7 @@ Dump generation on Windows, Linux and other non-Windows platforms has several ch
 
 Our goal is to generate core dumps that are on par with WER (Windows Error Reporting) crash dumps on any supported Linux platform. To the very least we want to enable the following:
 - automatic generation of minimal size minidumps. The quality and quantity of the information contained in the dump should be on par with the information contained in a traditional Windows mini-dump.
-- simple configurabilty by the user (not _su_!).
+- simple configurability by the user (not _su_!).
 
 Our solution at this time is to intercept any unhandled exception in the PAL layer of the runtime and have coreclr itself trigger and generate a "mini" core dump.
 

Diff for: docs/design/coreclr/jit/object-stack-allocation.md

@@ -137,7 +137,7 @@ but without field edges in the connection graph.
 * Only simple objects are stack allocated, arrays of constant size are not analyzed.
 * Only objects that are allocated unconditionally in the method are moved to the stack. An improvement here would
 be allocating other objects dynamically on the stack.
-* If at least one object in a method is stack allocated, all objects are conservatively reported as as TYPE_GC_BYREF
+* If at least one object in a method is stack allocated, all objects are conservatively reported as TYPE_GC_BYREF
 and a checked write barrier is used in the method.
 * All objects allocated on the stack also have a pre-header allocated. Pre-header is used for synchronization
 and hashing so we could eliminate it if we proved the object wasn't used for synchronization and hashing.

Diff for: docs/design/coreclr/profiling/Profiler Loading.md

@@ -4,7 +4,7 @@ To enable profiling set the following environment variables:
 - `CORECLR_PROFILER={_CLSID of profiler_}`
 
 # Finding the profiler library
-Once profiling is enabled there are two ways we load your profiler, with enviroment variables (cross-plat) or through the registry (Windows only)
+Once profiling is enabled there are two ways we load your profiler, with environment variables (cross-plat) or through the registry (Windows only)
 
 ## Environment Variable (cross-plat)
 Set one of the following (if all are set, the bitness-specific variables take precedence). The 32/64 ones specify which bitness of profiler is loaded

Diff for: docs/design/coreclr/profiling/ReJIT on Attach.md

@@ -14,7 +14,7 @@ To enable ReJIT on attach there is a new API `ICorProfilerInfo10::RequestReJITWi
                 [in, size_is(cFunctions)]  mdMethodDef methodIds[]);
 ```
 
-Conceptually this works the same as `ICorProfilerInfo4::RequestReJIT` except it will automatically ReJIT any methods that have inlined the target method(s) in the past. The arguments are the same except for the additon of `dwRejitFlags` as the first parameter. The valid values for this argument come from this enum:
+Conceptually this works the same as `ICorProfilerInfo4::RequestReJIT` except it will automatically ReJIT any methods that have inlined the target method(s) in the past. The arguments are the same except for the addition of `dwRejitFlags` as the first parameter. The valid values for this argument come from this enum:
 
 ```cpp
 typedef enum

Diff for: docs/design/coreclr/profiling/davbr-blog-archive/Attach2.md

@@ -15,7 +15,7 @@ Drawing by Magdalena Hermawan
 
 There are two fundamental ways your profiler can catch up on the current state of an application:
 
-- Lazy catch-up—as the profiler encounters new IDs, the profiler queries information about those IDs as it needs them, rather than assuming it has a full cache that’s always built up as the IDs are first created.  This is analogous to Dorothy meeting a new grown-up, and gracefully accepting the fact that that person exists.
+- Lazy catch-up—as the profiler encounters new IDs, the profiler queries information about those IDs as it needs them, rather than assuming it has a full cache that’s always built up as the IDs are first created.  This is analogous to Dorothy meeting a new grown-up, and gracefully accepting the fact that the person exists.
 - Enumeration—for certain kinds of IDs, the profiler can (at attach time) request a complete list of the currently active IDs and query information about them at that time.  Sort of like Dorothy first going to the Oz City Hall and looking up the birth records for everyone.
 
 Lazy catch-up is fairly self-explanatory.  For example, if your sampling profiler encounters an IP in a FunctionID you’ve never seen before, just look up whatever info you need about that FunctionID the first time you encounter it, rather than assuming you’d already built up a cache when the function was first JITted.  And if you discover that FunctionID resides in a module you’ve never seen before, then just look up whatever info you need about that ModuleID at that point, rather than assuming you already have a complete cache of all modules.  Many of you are already doing something like this today if you support sampling against regular NGENd images (since you don’t get JIT notifications of those functions anyway).

Diff for: docs/design/features/COM-activation.md

@@ -104,7 +104,7 @@ When `DllGetClassObject()` is called in a COM activation scenario, the following
         }
         ```
         Note this API is not exposed outside of `System.Private.CoreLib` and is subject to change at any time.
-    * The loading of the assembly will take place in a new [`AssemblyLoadContext`](https://docs.microsoft.com/dotnet/api/system.runtime.loader.assemblyloadcontext) for dependency isolation. Each assembly path will get a seperate `AssemblyLoadContext`. This means that if an assembly provides multiple COM servers all of the servers from that assembly will reside in the same `AssemblyLoadContext`.
+    * The loading of the assembly will take place in a new [`AssemblyLoadContext`](https://docs.microsoft.com/dotnet/api/system.runtime.loader.assemblyloadcontext) for dependency isolation. Each assembly path will get a separate `AssemblyLoadContext`. This means that if an assembly provides multiple COM servers all of the servers from that assembly will reside in the same `AssemblyLoadContext`.
     * The created `AssemblyLoadContext` will use an [`AssemblyDependencyResolver`](https://github.com/dotnet/runtime/issues/27787) that was supplied with the path to the assembly to load assemblies.
 1) The `IClassFactory` instance is returned to the caller of `DllGetClassObject()` to attempt class activation.
 

Diff for: docs/design/features/crossgen2-compilation-structure-enhancements.md

@@ -50,7 +50,7 @@ There are 3 sets of files to pass to crossgen2:
 ### Principles
 
 1. Ahead of time generated code exists to improve startup, and for some scenarios will be retained for the lifetime of the process.
-2. Our default scenario relies on on tiered compilation rejit for best performance.
+2. Our default scenario relies on tiered compilation rejit for best performance.
 3. Too much pregenerated code will negatively affect applications. Startup is the critical detail for most pregeneration scenarios, and for those, there is a blend of time to pull the file to the CPU (from disk, over the network, etc.) and to compile functions. Striking the right blend has been discovered to be critical.
 
 ### Proposed approach

Diff for: docs/design/features/source-generator-com.md

@@ -620,7 +620,7 @@ Cons:
 
 #### Option 5 (Selected Design): Only `GeneratedComInterfaceAttribute` attribute with Generated `ComWrappers`-derived type
 
-The built-in `ComImport` and `ComVisible` attributes have a lot of history and weird runtime behavior associated with them. Additionally the built-in `ComVisible` attribute actually takes a `bool` to determine if the applied to type is visible and it can be applied to methods as well to enable/disable COM visbility for the legacy automatic COM vtable generation that the .NET runtime has supported since .NET Framework 1.0. This option proposes introducing a single new attribute to cover the expected scenarios:
+The built-in `ComImport` and `ComVisible` attributes have a lot of history and weird runtime behavior associated with them. Additionally the built-in `ComVisible` attribute actually takes a `bool` to determine if the applied to type is visible and it can be applied to methods as well to enable/disable COM visibility for the legacy automatic COM vtable generation that the .NET runtime has supported since .NET Framework 1.0. This option proposes introducing a single new attribute to cover the expected scenarios:
 
 ```csharp
 [AttributeUsage(AttributeTargets.Interface)]

Diff for: docs/design/mono/components.md

@@ -24,7 +24,7 @@ time, instead of requiring custom builds of the runtime.
 For example, each of the following experiences requires different runtime
 capabilities:
 
-- Developer inner loop on on a mobile or WebAssembly workload: The runtime
+- Developer inner loop on a mobile or WebAssembly workload: The runtime
   should include support for the interpreter, hot reload, and the diagnostic
   server.
 - Release build iPhone app for the app store: The runtime should not include the

Diff for: docs/project/glossary.md

@@ -49,7 +49,7 @@ terminology.
 | TFM | [Target Framework Moniker](https://docs.microsoft.com/dotnet/standard/frameworks) such as `net6.0` or `netstandard2.0`. |
 | TPA | Trusted Platform Assemblies used to be a special set of assemblies that comprised the platform assemblies, when it was originally designed. As of today, it is simply the set of assemblies known to constitute the application. |
 | URT | Universal Runtime. Ancient name for what ended up being .NET, is used in the WinError facility name FACILITY_URT. |
-| UTC | [Universal Tuple Compiler](https://blogs.msdn.microsoft.com/vcblog/2013/06/12/optimizing-c-code-overview/). The Microsoft C++ optimizer back-end that that starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. |
+| UTC | [Universal Tuple Compiler](https://blogs.msdn.microsoft.com/vcblog/2013/06/12/optimizing-c-code-overview/). The Microsoft C++ optimizer back-end that starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. |
 | UWP | [Universal Windows Platform (UWP)](https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) is a platform-homogeneous application architecture available on every device that runs Windows 10. |
 | VSD | [Virtual Stub Dispatch](../design/coreclr/botr/virtual-stub-dispatch.md). Technique of using stubs for virtual method invocations instead of the traditional virtual method table. |
 | VM | Virtual machine. |

Diff for: eng/native/configurecompiler.cmake

@@ -133,7 +133,7 @@ elseif (CLR_CMAKE_HOST_UNIX)
         message("Address Sanitizer (asan) enabled")
       endif ()
       if (${__UBSAN_POS} GREATER -1)
-        # all sanitizier flags are enabled except alignment (due to heavy use of __unaligned modifier)
+        # all sanitizer flags are enabled except alignment (due to heavy use of __unaligned modifier)
         list(APPEND CLR_CXX_SANITIZERS
           "bool"
           bounds

Diff for: eng/packaging.targets

@@ -31,7 +31,7 @@
 
   <PropertyGroup Condition="'$(PreReleaseVersionLabel)' == 'servicing'">
     <!-- If no servicing version is set we need to default to 0 in order for dependency versions to
-    be calculated propertly, if we don't set it to 0, we would get the dependency version using the
+    be calculated properly, if we don't set it to 0, we would get the dependency version using the
     product Patch Version -->
     <ServicingVersion Condition="'$(ServicingVersion)' == ''">0</ServicingVersion>
 
@@ -260,13 +260,13 @@
     </ItemGroup>
   </Target>
 
-  <Target Name="ValidateAssemblyVersionsInRefPack" 
+  <Target Name="ValidateAssemblyVersionsInRefPack"
           Condition="'$(SkipValidateAssemblyVersion)' != 'true' and '$(_AssemblyInTargetingPack)' == 'true' and '$(PreReleaseVersionLabel)' == 'servicing'"
           AfterTargets="CoreCompile" >
     <Error Condition="'$(AssemblyVersion)' != '$(LastReleasedStableAssemblyVersion)'" Text="AssemblyVersion should match last released assembly version $(LastReleasedStableAssemblyVersion)" />
   </Target>
 
-  <Target Name="ValidateServicingVersionIsPropertlySet"
+  <Target Name="ValidateServicingVersionIsProperlySet"
           Condition="'$(PreReleaseVersionLabel)' == 'servicing' and '$(DotNetBuildFromSource)' != 'true'"
           AfterTargets="GenerateNuspec">
     <Error Condition="'$(ServicingVersion)' == '0'" Text="ServicingVersion is set to 0 and it should be an increment of the patch version from the last released package." />

Diff for: eng/pipelines/mono/templates/xplat-pipeline-job.yml

@@ -58,7 +58,7 @@ jobs:
     - name: buildProductArtifactName
       value: 'MonoProduct__${{ parameters.runtimeVariant }}_$(osGroup)$(osSubgroup)_$(archType)_$(buildConfig)'
 
-    # minijit and monointerpreter do not use seperate product builds.
+    # minijit and monointerpreter do not use separate product builds.
     - ${{ if or(eq(parameters.runtimeVariant, 'minijit'), eq(parameters.runtimeVariant, 'monointerpreter')) }}:
       - name : buildProductArtifactName
         value : 'MonoProduct___$(osGroup)$(osSubgroup)_$(archType)_$(buildConfig)'
@@ -107,7 +107,7 @@ jobs:
         value: 'Checked'
       ${{ if eq(parameters.liveRuntimeBuildConfig, 'debug') }}:
         value: 'Debug'
-        
+
     - name: priorityArg
       value: ''
 

Diff for: src/coreclr/System.Private.CoreLib/src/System/Reflection/LoaderAllocator.cs

@@ -10,7 +10,7 @@ namespace System.Reflection
     // We can destroy the unmanaged part of collectible type only after the managed part is definitely gone and thus
     // nobody can call/allocate/reference anything related to the collectible assembly anymore. A call to finalizer
     // alone does not guarantee that the managed part is gone. A malicious code can keep a reference to some object
-    // in a way that that survives finalization, or we can be running during shutdown where everything is finalized.
+    // in a way that it survives finalization, or we can be running during shutdown where everything is finalized.
     //
     // The unmanaged LoaderAllocator keeps a reference to the managed LoaderAllocator in long weak handle. If the long
     // weak handle is null, we can be sure that the managed part of the LoaderAllocator is definitely gone and that it

Diff for: src/coreclr/classlibnative/bcltype/objectnative.cpp

@@ -193,7 +193,7 @@ NOINLINE static Object* GetClassHelper(OBJECTREF objRef)
     return OBJECTREFToObject(refType);
 }
 
-// This routine is called by the Object.GetType() routine.   It is a major way to get the Sytem.Type
+// This routine is called by the Object.GetType() routine.   It is a major way to get the System.Type
 FCIMPL1(Object*, ObjectNative::GetClass, Object* pThis)
 {
     CONTRACTL

Diff for: src/coreclr/classlibnative/bcltype/varargsnative.cpp

@@ -91,7 +91,7 @@ static void InitCommon(VARARGS *data, VASigCookie** cookie)
     //                              += sizeOfArgs
     //                             /
     //   <arg1>                   /
-    // * <this>            ;; if an instance method (note: <this> is usally passed in
+    // * <this>            ;; if an instance method (note: <this> is usually passed in
     //                     ;; a register and wouldn't appear on the stack frame)
     //                     ;; higher memory
     //

Diff for: src/coreclr/debug/createdump/crashreportwriter.cpp

@@ -309,7 +309,7 @@ CrashReportWriter::Indent(std::string& text)
 }
 
 void
-CrashReportWriter::WriteSeperator(std::string& text)
+CrashReportWriter::WriteSeparator(std::string& text)
 {
     if (m_comma)
     {
@@ -323,7 +323,7 @@ void
 CrashReportWriter::OpenValue(const char* key, char marker)
 {
     std::string text;
-    WriteSeperator(text);
+    WriteSeparator(text);
     if (key != nullptr)
     {
         text.append("\"");
@@ -354,7 +354,7 @@ void
 CrashReportWriter::WriteValue(const char* key, const char* value)
 {
     std::string text;
-    WriteSeperator(text);
+    WriteSeparator(text);
     text.append("\"");
     text.append(key);
     text.append("\" : \"");

Diff for: src/coreclr/debug/createdump/crashreportwriter.h

@@ -31,7 +31,7 @@ class CrashReportWriter
     void Write(const std::string& text);
     void Write(const char* buffer);
     void Indent(std::string& text);
-    void WriteSeperator(std::string& text);
+    void WriteSeparator(std::string& text);
     void OpenValue(const char* key, char marker);
     void CloseValue(char marker);
     bool OpenWriter(const char* fileName);