chore: fix some comments (#105504)

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

docs/design/coreclr/jit/profile-count-reconstruction.md

@@ -111,7 +111,7 @@ So solution techniques that can leverage sparseness are of particular interest.
 
 Note the matrix $\boldsymbol I - \boldsymbol P$ has non-negative diagonal elements and negative non-diagonal elements, since all entries of $\boldsymbol P$ are in the range [0,1].
 
-If we further restrict ourselves to the case where $p_{i,i} \lt 1$ (meaning there are are no infinite self-loops) then all the diagonal entries are positive and the matrix has an inverse with no negative elements.
+If we further restrict ourselves to the case where $p_{i,i} \lt 1$ (meaning there are no infinite self-loops) then all the diagonal entries are positive and the matrix has an inverse with no negative elements.
 
 Such matrices are known as M-matrices.
 

docs/design/mono/web/aot.md

@@ -105,7 +105,7 @@ It is possible to use LLVM in AOT mode. This is implemented by compiling methods
 
 ### Full AOT mode
 
-Some platforms like the iphone prohibit JITted code, using technical and/or legal means. This is a significant problem for the mono runtime, since it generates a lot of code dynamically, using either the JIT or more low-level code generation macros. To solve this, the AOT compiler is able to function in full-aot or aot-only mode, where it generates and saves all the neccesary code in the aot image, so at runtime, no code needs to be generated. There are two kinds of code which needs to be considered:
+Some platforms like the iphone prohibit JITted code, using technical and/or legal means. This is a significant problem for the mono runtime, since it generates a lot of code dynamically, using either the JIT or more low-level code generation macros. To solve this, the AOT compiler is able to function in full-aot or aot-only mode, where it generates and saves all the necessary code in the aot image, so at runtime, no code needs to be generated. There are two kinds of code which needs to be considered:
 
 -   wrapper methods, that is methods whose IL is generated dynamically by the runtime. They are handled by generating them in the add_wrappers () function, then emitting them as 'extra' methods.
 -   trampolines and other small hand generated pieces of code. They are handled in an ad-hoc way in the emit_trampolines () function.

docs/design/mono/web/exception-handling.md

@@ -114,7 +114,7 @@ Currently, exceptions are raised by calling mono_raise_exception () in the middl
 
 -   To allow mono_raise_exception () to unwind through native code, we need to save the LMF structures which can add a lot of overhead even in the common case when no exception is thrown. So this is not zero-cost exception handling.
 
-An alternative might be to use a JNI style set-pending-exception API. Runtime code could call mono_set_pending_exception (), then return to its caller with an error indication allowing the caller to clean up. When execution returns to managed code, then managed-\>native wrapper could check whenever there is a pending exception and throw it if neccesary. Since we already check for pending thread interruption, this would have no overhead, allowing us to drop the LMF saving/restoring code, or significant parts of it.
+An alternative might be to use a JNI style set-pending-exception API. Runtime code could call mono_set_pending_exception (), then return to its caller with an error indication allowing the caller to clean up. When execution returns to managed code, then managed-\>native wrapper could check whenever there is a pending exception and throw it if necessary. Since we already check for pending thread interruption, this would have no overhead, allowing us to drop the LMF saving/restoring code, or significant parts of it.
 
 ### libunwind
 

docs/design/mono/web/linear-ir.md

@@ -96,7 +96,7 @@ The JIT allocates a large number of vregs. Most of these are created during the
 ### Transitioning between the two states
 
 -   Most vregs start out being local. Others, like the ones representing the arguments and locals of a method, start out being global.
--   Some transformations done by the JIT can break the invariant that an lvreg is local to a basic block. There is a separate pass, mono_handle_global_vregs (), which verifies this invariant and transforms lvregs into global vregs if neccesary. This pass also does the opposite transformation, by transforming global vregs used only in one bblock into an lvreg.
+-   Some transformations done by the JIT can break the invariant that an lvreg is local to a basic block. There is a separate pass, mono_handle_global_vregs (), which verifies this invariant and transforms lvregs into global vregs if necessary. This pass also does the opposite transformation, by transforming global vregs used only in one bblock into an lvreg.
 -   If an address of a vreg needs to be taken, the vreg is transformed into a global vreg.
 
 JIT Passes

docs/design/mono/web/register-allocation.md

@@ -56,7 +56,7 @@ Some variables might already be allocated to hardware registers during the globa
 
 #### Floating point stack
 
-The x86 architecture uses a floating point register stack instead of a set of fp registers. The allocator supports this by a post-processing pass which keeps track of the height of the fp stack, and spills/loads values from the stack as neccesary.
+The x86 architecture uses a floating point register stack instead of a set of fp registers. The allocator supports this by a post-processing pass which keeps track of the height of the fp stack, and spills/loads values from the stack as necessary.
 
 #### Calls
 

src/coreclr/jit/fginline.cpp

@@ -1975,7 +1975,7 @@ void Compiler::fgInsertInlineeArgument(
 //    * Passing of call arguments via temps
 //
 //    Newly added statements are placed just after the original call
-//    and are are given the same inline context as the call any calls
+//    and are given the same inline context as the call any calls
 //    added here will appear to have been part of the immediate caller.
 //
 Statement* Compiler::fgInlinePrependStatements(InlineInfo* inlineInfo)

src/coreclr/tools/Common/Compiler/InstructionSetSupport.cs

@@ -201,7 +201,7 @@ private static Dictionary<string, InstructionSet> ComputeInstructSetSupportForAr
             var support = new Dictionary<string, InstructionSet>();
             foreach (var instructionSet in InstructionSetFlags.ArchitectureToValidInstructionSets(architecture))
             {
-                // Only instruction sets with associated R2R enum values are are specifiable
+                // Only instruction sets with associated R2R enum values are specifiable
                 if (instructionSet.Specifiable)
                     support.Add(instructionSet.Name, instructionSet.InstructionSet);
             }
@@ -214,7 +214,7 @@ private static InstructionSetFlags ComputeNonSpecifiableInstructionSetSupportFor
             var support = new InstructionSetFlags();
             foreach (var instructionSet in InstructionSetFlags.ArchitectureToValidInstructionSets(architecture))
             {
-                // Only instruction sets with associated R2R enum values are are specifiable
+                // Only instruction sets with associated R2R enum values are specifiable
                 if (!instructionSet.Specifiable)
                     support.AddInstructionSet(instructionSet.InstructionSet);
             }

src/libraries/System.ComponentModel.TypeConverter/src/System/ComponentModel/TrimSafeReflectionHelper.cs

@@ -7,7 +7,7 @@
 namespace System.ComponentModel
 {
     [UnconditionalSuppressMessage("ReflectionAnalysis", "IL2070:UnrecognizedReflectionPattern",
-        Justification = "Class is only called with types are are registered or protected with [DynamicallyAccessedMemberTypes].")]
+        Justification = "Class is only called with types are registered or protected with [DynamicallyAccessedMemberTypes].")]
     internal static class TrimSafeReflectionHelper
     {
         public static PropertyInfo[] GetProperties(Type type, BindingFlags bindingAttr) => type.GetProperties(bindingAttr);

src/libraries/System.Runtime.Serialization.Xml/tests/XsdDataContractExporterTests/SerializationTypes/PartialTrust.cs

@@ -64,7 +64,7 @@ public class AttributeOnlyIXmlSerializable : IXmlSerializable
         {
             public AttributeOnlyIXmlSerializable()
             {
-                // This was not commented in NetFx. It clutters output though and seems unneccesary for our needs.
+                // This was not commented in NetFx. It clutters output though and seems unnecessary for our needs.
                 //Console.WriteLine("Default Ctor");
             }
 

src/mono/mono/component/marshal-ilgen.c

@@ -1044,7 +1044,7 @@ emit_marshal_char_ilgen (EmitMarshalContext *m, int argnum, MonoType *t,
 static int
 emit_marshal_custom_ilgen_throw_exception (MonoMethodBuilder *mb, const char *exc_nspace, const char *exc_name, const char *msg, MarshalAction action)
 {
-	/* Throw exception and emit compensation code, if neccesary */
+	/* Throw exception and emit compensation code, if necessary */
 	switch (action) {
 	case MARSHAL_ACTION_CONV_IN:
 	case MARSHAL_ACTION_MANAGED_CONV_IN:

src/mono/mono/mini/mini-amd64.c

@@ -5835,7 +5835,7 @@ mono_arch_output_basic_block (MonoCompile *cfg, MonoBasicBlock *bb)
 #else
 			// NT does not have varargs rax use, and NT ABI does not have red zone.
 			// Use red-zone mov/jmp instead of push/ret to preserve call/ret speculation stack.
-			// FIXME Just like NT the direct cases are are not ideal.
+			// FIXME Just like NT the direct cases are not ideal.
 			amd64_mov_membase_reg (code, AMD64_RSP, -8, AMD64_RAX, 8);
 			code = amd64_handle_varargs_call (cfg, code, call, FALSE);
 #ifdef MONO_ARCH_HAVE_SWIFTCALL