Use CIL instead of MSIL (dotnet#40554)

docs/core/diagnostics/dotnet-dump.md

@@ -169,7 +169,7 @@ dotnet-dump analyze <dump_path> [-h|--help] [-c|--command]
 | `dumpgcdata`                                        | Displays information about the GC data. |
 | `dumpgen`                                           | Displays heap content for the specified generation. |
 | `dumpheap`                                          | Displays info about the garbage-collected heap and collection statistics about objects. |
-| `dumpil`                                            | Displays the Microsoft intermediate language (MSIL) that's associated with a managed method. |
+| `dumpil`                                            | Displays the common intermediate language (CIL) that's associated with a managed method. |
 | `dumplog`                                           | Writes the contents of an in-memory stress log to the specified file. |
 | `dumpmd`                                            | Displays information about the `MethodDesc` structure at the specified address. |
 | `dumpmodule`                                        | Displays information about the module at the specified address. |

docs/core/diagnostics/sos-debugging-extension.md

@@ -41,7 +41,7 @@ The following table of commands is also available under **Help** or **soshelp**.
 | **DumpClass** \<*EEClass address*> | Displays information about the `EEClass` structure associated with a type.<br /><br /> The **DumpClass** command displays static field values but does not display nonstatic field values.<br /><br /> Use the **DumpMT**, **DumpObj**, **Name2EE**, or **Token2EE** command to get an `EEClass` structure address. |
 | **DumpDomain** [\<*domain address*>] | Enumerates each <xref:System.Reflection.Assembly> object that's loaded within the specified <xref:System.AppDomain> object address.  When called with no parameters, the **DumpDomain** command lists all <xref:System.AppDomain> objects in a process. Since .NET (Core) only has one <xref:System.AppDomain>, **DumpDomain** only returns one object. |
 | **DumpHeap** [**-stat**] [**-strings**] [**-short**] [**-min** \<*size*>] [**-max** \<*size*>] [**-thinlock**] [**-startAtLowerBound**] [**-mt** \<*MethodTable address*>] [**-type** \<*partial type name*>] [*start* [*end*]] | Displays information about the garbage-collected heap and collection statistics about objects.<br /><br /> The **DumpHeap** command displays a warning if it detects excessive fragmentation in the garbage collector heap.<br /><br /> The **-stat** option restricts the output to the statistical type summary.<br /><br /> The **-strings** option restricts the output to a statistical string value summary.<br /><br /> The **-short** option limits output to just the address of each object. This lets you easily pipe output from the command to another debugger command for automation.<br /><br /> The **-min** option ignores objects that are less than the `size` parameter, specified in bytes.<br /><br /> The **-max** option ignores objects that are larger than the `size` parameter, specified in bytes.<br /><br /> The **-thinlock** option reports ThinLocks.  For more information, see the **SyncBlk** command.<br /><br /> The `-startAtLowerBound` option forces the heap walk to begin at the lower bound of a supplied address range. During the planning phase, the heap is often not walkable because objects are being moved. This option forces **DumpHeap** to begin its walk at the specified lower bound. You must supply the address of a valid object as the lower bound for this option to work. You can display memory at the address of a bad object to manually find the next method table. If the garbage collection is currently in a call to `memcopy`, you may also be able to find the address of the next object by adding the size to the start address, which is supplied as a parameter.<br /><br /> The **-mt** option lists only those objects that correspond to the specified `MethodTable` structure.<br /><br />The **-type** option lists only those objects whose type name is a substring match of the specified string.<br /><br />The `start` parameter begins listing from the specified address.<br /><br />The `end` parameter stops listing at the specified address. |
-| **DumpIL** \<*Managed DynamicMethod object*> &#124;       \<*DynamicMethodDesc pointer*> &#124;        \<*MethodDesc pointer*> | Displays the Microsoft intermediate language (MSIL) that is associated with a managed method.<br /><br /> Dynamic MSIL is emitted differently than MSIL that's loaded from an assembly. Dynamic MSIL refers to objects in a managed object array rather than to metadata tokens. |
+| **DumpIL** \<*Managed DynamicMethod object*> &#124;       \<*DynamicMethodDesc pointer*> &#124;        \<*MethodDesc pointer*> | Displays the common intermediate language (CIL) that's associated with a managed method.<br /><br /> Dynamic CIL is emitted differently than CIL that's loaded from an assembly. Dynamic CIL refers to objects in a managed object array rather than to metadata tokens. |
 | **DumpLog** [**-addr** \<*addressOfStressLog*>] [<*Filename*>] | Writes the contents of an in-memory stress log to the specified file. If you do not specify a name, this command creates a file called StressLog.txt in the current directory.<br /><br /> The in-memory stress log helps you diagnose stress failures without using locks or I/O. To enable the stress log, set the following registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\\.NETFramework:<br /><br /> (DWORD) StressLog = 1<br /><br /> (DWORD) LogFacility = 0xffffffff<br /><br /> (DWORD) StressLogSize = 65536<br /><br /> The optional `-addr` option lets you specify a stress log other than the default log. |
 | **DumpMD** \<*MethodDesc address*> | Displays information about a `MethodDesc` structure at the specified address.<br /><br /> You can use the **IP2MD** command to get the `MethodDesc` structure address from a managed function. |
 | **DumpMT** [**-MD**] \<*MethodTable address*> | Displays information about a method table at the specified address. Specifying the **-MD** option displays a list of all methods defined with the object.<br /><br /> Each managed object contains a method table pointer. |
@@ -135,7 +135,7 @@ By default you can reach all the SOS commands by entering: `sos [command_name]`.
 |    `dumpgcdata`                       | Displays information about the GC data. |
 |    `dumpgen`                          | Displays heap content for the specified generation. |
 |    `dumpheap`                         | Displays info about the garbage-collected heap and collection statistics about objects. |
-|    `dumpil`                           | Displays the Microsoft intermediate language (MSIL) that's associated with a managed method. |
+|    `dumpil`                           | Displays the common intermediate language (CIL) that's associated with a managed method. |
 |    `dumplog`                          | Writes the contents of an in-memory stress log to the specified file. |
 |    `dumpmd`                           | Displays information about the `MethodDesc` structure at the specified address. |
 |    `dumpmodule`                       | Displays information about the module at the specified address. |

docs/core/whats-new/dotnet-8/containers.md

@@ -68,7 +68,7 @@ For more information, see the [Improving multi-platform container support](https
 
 ### ASP.NET composite images
 
-As part of an effort to improve containerization performance, new ASP.NET Docker images are available that have a composite version of the runtime. This composite is built by compiling multiple MSIL assemblies into a single ready-to-run (R2R) output binary. Because these assemblies are embedded into a single image, jitting takes less time, and the startup performance of apps improves. The other big advantage of the composite over the regular ASP.NET image is that the composite images have a smaller size on disk.
+As part of an effort to improve containerization performance, new ASP.NET Docker images are available that have a composite version of the runtime. This composite is built by compiling multiple CIL assemblies into a single ready-to-run (R2R) output binary. Because these assemblies are embedded into a single image, jitting takes less time, and the startup performance of apps improves. The other big advantage of the composite over the regular ASP.NET image is that the composite images have a smaller size on disk.
 
 There is a caveat to be aware of. Since composites have multiple assemblies embedded into one, they have tighter version coupling. Apps can't use custom versions of framework or ASP.NET binaries.
 

docs/csharp/advanced-topics/expression-trees/index.md

@@ -17,8 +17,8 @@ You've likely already written code that uses Expression trees. Entity Framework'
 When you want to have a richer interaction, you need to use *Expression Trees*. Expression Trees represent code as a structure that you examine, modify, or execute. These tools give you the power to manipulate code during run time. You write code that examines running algorithms, or injects new capabilities. In more advanced scenarios, you modify running algorithms and even translate C# expressions into another form for execution in another environment.
 
 You compile and run code represented by expression trees. Building and running expression trees enables dynamic modification of executable code, the execution of LINQ queries in various databases, and the creation of dynamic queries. For more information about expression trees in LINQ, see [How to use expression trees to build dynamic queries](../../programming-guide/concepts/linq/how-to-use-expression-trees-to-build-dynamic-queries.md).
-  
-Expression trees are also used in the dynamic language runtime (DLR) to provide interoperability between dynamic languages and .NET and to enable compiler writers to emit expression trees instead of Microsoft intermediate language (MSIL). For more information about the DLR, see [Dynamic Language Runtime Overview](../../../framework/reflection-and-codedom/dynamic-language-runtime-overview.md).
+
+Expression trees are also used in the dynamic language runtime (DLR) to provide interoperability between dynamic languages and .NET and to enable compiler writers to emit expression trees instead of common intermediate language (CIL). For more information about the DLR, see [Dynamic Language Runtime Overview](../../../framework/reflection-and-codedom/dynamic-language-runtime-overview.md).
 
 You can have the C# or Visual Basic compiler create an expression tree for you based on an anonymous lambda expression, or you can create expression trees manually by using the <xref:System.Linq.Expressions> namespace.
 

docs/csharp/language-reference/compiler-options/security.md

@@ -2,9 +2,9 @@
 description: "C# Compiler Options for security. These options control signing assemblies or address space layout."
 title: "C# Compiler Options - security options"
 ms.date: 03/12/2021
-f1_keywords: 
+f1_keywords:
   - "cs.build.options"
-helpviewer_keywords: 
+helpviewer_keywords:
   - "PublicSign compiler option [C#]"
   - "DelaySign compiler option [C#]"
   - "KeyFile compiler option [C#]"
@@ -61,7 +61,7 @@ Specifies the name of the cryptographic key container.
 <KeyContainer>container</KeyContainer>
 ```
 
-`container` is the name of the strong name key container. When the **KeyContainer** option is used, the compiler creates a sharable component. The compiler inserts a public key from the specified container into the assembly manifest and signs the final assembly with the private key. To generate a key file, type `sn -k file` at the command line. `sn -i` installs the key pair into a container. This option isn't supported when the compiler runs on CoreCLR. To sign an assembly when building on CoreCLR, use the [**KeyFile**](#keyfile) option. If you compile with [**TargetType**](output.md#targettype), the name of the key file is held in the module and incorporated into the assembly when you compile this module into an assembly with [**AddModules**](inputs.md#addmodules). You can also specify this option as a custom attribute (<xref:System.Reflection.AssemblyKeyNameAttribute?displayProperty=nameWithType>) in the source code for any Microsoft intermediate language (MSIL) module. You can also pass your encryption information to the compiler with [**KeyFile**](#keyfile). Use [**DelaySign**](#delaysign) to add the public key  to the assembly manifest but signing the assembly until it has been tested. For more information, see [Creating and Using Strong-Named Assemblies](../../../standard/assembly/create-use-strong-named.md) and [Delay Signing an Assembly](../../../standard/assembly/delay-sign.md).
+`container` is the name of the strong name key container. When the **KeyContainer** option is used, the compiler creates a sharable component. The compiler inserts a public key from the specified container into the assembly manifest and signs the final assembly with the private key. To generate a key file, type `sn -k file` at the command line. `sn -i` installs the key pair into a container. This option isn't supported when the compiler runs on CoreCLR. To sign an assembly when building on CoreCLR, use the [**KeyFile**](#keyfile) option. If you compile with [**TargetType**](output.md#targettype), the name of the key file is held in the module and incorporated into the assembly when you compile this module into an assembly with [**AddModules**](inputs.md#addmodules). You can also specify this option as a custom attribute (<xref:System.Reflection.AssemblyKeyNameAttribute?displayProperty=nameWithType>) in the source code for any common intermediate language (CIL) module. You can also pass your encryption information to the compiler with [**KeyFile**](#keyfile). Use [**DelaySign**](#delaysign) to add the public key  to the assembly manifest but signing the assembly until it has been tested. For more information, see [Creating and Using Strong-Named Assemblies](../../../standard/assembly/create-use-strong-named.md) and [Delay Signing an Assembly](../../../standard/assembly/delay-sign.md).
 
 ## HighEntropyVA