Partial grammar review

Author: BillWagner

docs/csharp/language-reference/compiler-options/code-generation.md

@@ -14,25 +14,25 @@ helpviewer_keywords:
 
 The following options control compiler inputs. The new MSBuild syntax is shown in **Bold**. The older `csc.exe` syntax is shown in `code style`.
 
-- **DebugType** / `-debug`: Emit (or do not Emit) debugging information.
+- **DebugType** / `-debug`: Emit (or don't Emit) debugging information.
 - **Optimize** / `-optimize`: Enable optimizations.
 - **Deterministic** / `-deterministic`: Produce byte-for-byte equivalent output from the same input source.
 - **ProduceOnlyReferenceAssembly** / `-refonly`: Produce a reference assembly, instead of a full assembly, as the primary output.
 
 ## DebugType
 
-The **DebugType** option causes the compiler to generate debugging information and place it in the output file or files. This may be affected by the selected build configuration: *Debug* or *Release*.
+The **DebugType** option causes the compiler to generate debugging information and place it in the output file or files. Debugging information may be affected by the selected build configuration: *Debug* or *Release*.
 
 ```xml
 <DebugType>Full</DebugType>
 ```
 
-The value of this element can be either `full` or `pdbonly`. The *full* argument, which is in effect if you do not specify *pdbonly*, enables attaching a debugger to the running program. Specifying *pdbonly* allows source code debugging when the program is started in the debugger but will only display assembler when the running program is attached to the debugger. Use this option to create debug builds. If **-debug**, **-debug+**, or **-debug:full** is not specified, you will not be able to debug the output file of your program. If you use *full*, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with *full*. We recommend *pdbonly* or no PDB for generating release code.
+The value of this element can be either `full` or `pdbonly`. The *full* argument, which is in effect if you don't specify *pdbonly*, enables attaching a debugger to the running program. Specifying *pdbonly* allows source code debugging when the program is started in the debugger but will only display assembler when the running program is attached to the debugger. Use this option to create debug builds. If **-debug**, **-debug+**, or **-debug:full** isn't specified, you can't debug the output file of your program. If you use *full*, be aware that there's some impact on the speed and size of JIT optimized code and a small impact on code quality with *full*. We recommend *pdbonly* or no PDB for generating release code.
 
 > [!NOTE]
 > One difference between *pdbonly* and *full* is that with *full* the compiler emits a <xref:System.Diagnostics.DebuggableAttribute>, which is used to tell the JIT compiler that debug information is available. Therefore, you will get an error if your code contains the <xref:System.Diagnostics.DebuggableAttribute> set to false if you use *full*.
 
-For more information on how to configure the debug performance of an application, see [Making an Image Easier to Debug](../../../framework/debug-trace-profile/making-an-image-easier-to-debug.md). To change the location of the .pdb file, see [**PdbFile**](./advanced.md#pdbfile).
+For more information on how to configure the debug performance of an application, see [Making an Image Easier to Debug](../../../framework/debug-trace-profile/making-an-image-easier-to-debug.md). To change the location of the *.pdb* file, see [**PdbFile**](./advanced.md#pdbfile).
 
 ## Optimize
 
@@ -76,7 +76,7 @@ By default, compiler output from a given set of inputs is unique, since the comp
 - The Common Language Runtime (CLR) platform on which the compiler is run.
 - The value of `%LIBPATH%`, which can affect analyzer dependency loading.
 
-Deterministic compilation can be used for establishing whether a binary is compiled from a trusted source. This can be useful when the source is publicly available. It can also determine whether build steps that are dependent on changes to binary used in the build process.
+Deterministic compilation can be used for establishing whether a binary is compiled from a trusted source. Deterministic output can be useful when the source is publicly available. It can also determine whether build steps that are dependent on changes to binary used in the build process.
 
 ## ProduceOnlyReferenceAssembly
 

docs/csharp/language-reference/compiler-options/errors-warnings.md

@@ -29,13 +29,13 @@ The following options control how the compiler reports errors and warnings. The
 
 ## TreatWarningsAsErrors
 
-The **TreatWarningsAsErrors** option treats all warnings as errors. You can also use the **WarningsAsError** to set only some warnings as errors. If you turn on **TreatWarningsAsErrors**, you can use **WarningsNotAsError** to list warnings that should not be treated as errors.
+The **TreatWarningsAsErrors** option treats all warnings as errors. You can also use the **WarningsAsError** to set only some warnings as errors. If you turn on **TreatWarningsAsErrors**, you can use **WarningsNotAsError** to list warnings that shouldn't be treated as errors.
 
 ```xml
 <TreatWarningsAsErrors></TreatWarningsAsErrors>
 ```
 
-Any messages that would ordinarily be reported as warnings are instead reported as errors, and the build process is halted (no output files are built). By default, **TreatWarningsAsErrors** isn't in effect, which means warnings don't prevent the generation of an output file. Optionally, if you want only a few specific warnings to be treated as errors, you may specify a comma-separated list of warning numbers to treat as errors. The set of all nullability warnings can be specified with the **Nullable** shorthand. Use **WarningLevel** to specify the level of warnings that you want the compiler to display. Use **DisabledWarnings** to disable certain warnings.
+All warning messages are instead reported as errors. The build process halts (no output files are built). By default, **TreatWarningsAsErrors** isn't in effect, which means warnings don't prevent the generation of an output file. Optionally, if you want only a few specific warnings to be treated as errors, you may specify a comma-separated list of warning numbers to treat as errors. The set of all nullability warnings can be specified with the **Nullable** shorthand. Use **WarningLevel** to specify the level of warnings that you want the compiler to display. Use **DisabledWarnings** to disable certain warnings.
 
 ## WarningLevel
 
@@ -45,7 +45,7 @@ The **WarningLevel** option specifies the warning level for the compiler to disp
 <WarningLevel>3</WarningLevel>
 ```
 
-The element value is the warning level you want displayed for the compilation: Lower numbers show only high severity warnings; higher numbers show more warnings. The value must be zero or a positive integer:
+The element value is the warning level you want displayed for the compilation: Lower numbers show only high severity warnings. Higher numbers show more warnings. The value must be zero or a positive integer:
 
 |Warning level|Meaning|
 |-------------------|-------------|
@@ -67,7 +67,7 @@ The **DisabledWarnings** option lets you suppress the compiler from displaying o
 <DisabledWarnings>number2, number2</DisabledWarnings>
 ```
 
-`number1`, `number2` Warning number(s) that you want the compiler to suppress. You should only specify the numeric part of the warning identifier. For example, if you want to suppress *CS0028*, you could specify `<DisabledWarnings>28</DisabledWarnings>`. The compiler will silently ignore warning numbers passed to **DisabledWarnings** that were valid in previous releases, but that have been removed from the compiler. For example, *CS0679* was valid in the compiler in Visual Studio .NET 2002 but was subsequently removed.
+`number1`, `number2` Warning number(s) that you want the compiler to suppress. You specify the numeric part of the warning identifier. For example, if you want to suppress *CS0028*, you could specify `<DisabledWarnings>28</DisabledWarnings>`. The compiler silently ignores warning numbers passed to **DisabledWarnings** that were valid in previous releases, but that have been removed. For example, *CS0679* was valid in the compiler in Visual Studio .NET 2002 but was removed later.
 
  The following warnings cannot be suppressed by the **DisabledWarnings** option:
 
@@ -83,7 +83,7 @@ Specify a ruleset file that configures specific diagnostics.
 <CodeAnalysisRuleSet>MyConfiguration.ruleset</CodeAnalysisRuleSet>
 ```
 
-Where `MyConfiguration.ruleset` is the path to the ruleset file. For more information on using rule sets set the article in the [Visual Studio documentation on Rule sets](visualstudio/code-quality/using-rule-sets-to-group-code-analysis-rules).
+Where `MyConfiguration.ruleset` is the path to the ruleset file. For more information on using rule sets, see the article in the [Visual Studio documentation on Rule sets](visualstudio/code-quality/using-rule-sets-to-group-code-analysis-rules).
 
 ## ErrorLog
 
@@ -93,7 +93,7 @@ Specify a file to log all compiler and analyzer diagnostics.
 <ErrorLog>MyConfiguration.ruleset</ErrorLog>
 ```
 
-This causes the compiler to output a [Static Analysis Results Interchange Format (SARIF) log](https://github.com/microsoft/sarif-tutorials/blob/main/docs/1-Introduction.md#:~:text=What%20is%20SARIF%3F,for%20use%20by%20simpler%20tools) as a part of the build. SARIF logs are typically read by other tools that analyze the results from compiler and analyzer diagnostics.
+The **ErrorLog** option causes the compiler to output a [Static Analysis Results Interchange Format (SARIF) log](https://github.com/microsoft/sarif-tutorials/blob/main/docs/1-Introduction.md#:~:text=What%20is%20SARIF%3F,for%20use%20by%20simpler%20tools). SARIF logs are typically read by tools that analyze the results from compiler and analyzer diagnostics.
 
 ## ReportAnalyzer
 
@@ -103,4 +103,4 @@ Report additional analyzer information, such as execution time.
 <ReportAnalyzer>true</ReportAnalyzer>
 ```
 
-The **ReportAnalyzer** options causes the compiler to emit extra MSBuild log information that details the performance characteristics of analyzers in the build. It is typically used by analyzer authors as part of validating the analyzer.
+The **ReportAnalyzer** option causes the compiler to emit extra MSBuild log information that details the performance characteristics of analyzers in the build. It's typically used by analyzer authors as part of validating the analyzer.

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

@@ -16,7 +16,7 @@ ms.assetid: d3403556-1816-4546-a782-e8223a772e44
 
 This section describes the options interpreted by the C# compiler. There are two different ways to set compiler options in .NET projects:
 
-- ***Specify option in your \*.csproj file***: You can add XML elements for any compiler option in your *\*.csproj* file. The element name is the same as the compiler option. The value of the XML element sets the value of the compiler option. For more details on setting options in project files see the article [MSBuild properties for .NET SDK Projects](../../../core/project-sdk/msbuild-props.md).
+- ***Specify option in your \*.csproj file***: You can add XML elements for any compiler option in your *\*.csproj* file. The element name is the same as the compiler option. The value of the XML element sets the value of the compiler option. For more information on setting options in project files, see the article [MSBuild properties for .NET SDK Projects](../../../core/project-sdk/msbuild-props.md).
 - ***Using the Visual Studio Property pages***: Visual Studio provides property pages to edit build properties. You can learn more about them see the article [Manage project and solution properties - Windows](https://docs.microsoft.com/visualstudio/ide/managing-project-and-solution-properties#c-visual-basic-and-f-projects) or [Manage project and solution properties - Mac](https://docs.microsoft.com/visualstudio/mac/managing-solutions-and-project-properties).
 
 ## .NET Framework projects