Corrected Typos and grammar (#20658)

* Corrected some typos and grammar as per English language guidelines.

* Reverted some of the changes

* Reverted back some changes Phase 2

Documentation/building/cross-building.md

@@ -24,7 +24,7 @@ Through cross compilation, on Linux it is possible to build CoreCLR for arm or a
 Requirements for targetting Debian based distros
 ------------------------------------------------
 
-You need a Debian based host and the following packages needs to be installed:
+You need a Debian based host and the following packages need to be installed:
 
     ben@ubuntu ~/git/coreclr/ $ sudo apt-get install qemu qemu-user-static binfmt-support debootstrap
 
@@ -55,7 +55,7 @@ To build them, use the following steps:
 
 Generating the rootfs
 ---------------------
-The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an rootfs as this is what CoreCLR targets.
+The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate a rootfs as this is what CoreCLR targets.
 
     Usage: ./cross/build-rootfs.sh [BuildArch] [LinuxCodeName] [lldbx.y] [--skipunmount]
     BuildArch can be: arm(default), armel, arm64, x86
@@ -68,7 +68,7 @@ For example, to generate an arm rootfs:
 
     ben@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh arm
 
-You can choose Linux code name to match your target, give `vivid` for `Ubuntu 15.04`, `wily` for `Ubuntu 15.10`. Default is `trusty`, version `Ubuntu 14.04`.
+You can choose Linux code name to match your target, give `vivid` for `Ubuntu 15.04`, `wily` for `Ubuntu 15.10`. The default is `trusty`, version `Ubuntu 14.04`.
 
     ben@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh arm wily
 
@@ -80,7 +80,7 @@ For example, to generate an armel rootfs:
 
     hqu@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh armel
 
-You can choose code name to match your target, give `jessie` for `Debian`, `tizen` for `Tizen`. Default is `jessie`.
+You can choose code name to match your target, give `jessie` for `Debian`, `tizen` for `Tizen`. The default is `jessie`.
 
     hque@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh armel tizen
 
@@ -101,7 +101,7 @@ And with:
 
     ben@ubuntu ~/git/coreclr/ $ ROOTFS_DIR=/home/ben/coreclr-cross/arm ./build.sh arm debug verbose cross
 
-As usual the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.BuildType/`
+As usual, the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.BuildType/`
 
 
 Compiling System.Private.CoreLib for ARM Linux

Documentation/building/crossgen.md

@@ -7,14 +7,14 @@ Introduction
 When you create a .NET assembly using C# compiler, your assembly contains only MSIL code.
 When the app runs, the JIT compiler translates the MSIL code into native code, before the CPU can execute them.
 This execution model has some advantages. For example, your assembly code can be portable across all platforms and architectures that support .NET Core.
-However, this portability comes with a performance cost. Your app starts up more slowly, because the JIT compiler has to spend time to translate the code.
+However, this portability comes with a performance cost. Your app starts up more slowly because the JIT compiler has to spend time to translate the code.
 
 To help make your app start up faster, CoreCLR includes a tool called CrossGen, which can pre-compile the MSIL code into native code.
 
 Getting CrossGen
 ----------------
 
-If you build CoreCLR yourself, the CrossGen tool (`crossgen.exe` on Windows, or `crossgen` on other platforms) is created as part of the build, and stored in the same output directory as other CoreCLR binaries.
+If you build CoreCLR yourself, the CrossGen tool (`crossgen.exe` on Windows, or `crossgen` on other platforms) is created as part of the build and stored in the same output directory as other CoreCLR binaries.
 If you install CoreCLR using a NuGet package, you can find CrossGen in the `tools` folder of the NuGet package.
 
 Regardless of how you obtain CrossGen, it is very important that it must match other CoreCLR binaries.
@@ -55,13 +55,13 @@ Using native images
 -------------------
 
 Running CrossGen on an assembly creates a "native image" file, with the extension of `.ni.dll` or `.ni.exe`.
-You should include the native images in your app, either by replacing the original MSIL assemblies with the native images, or by putting the native images next to the MSIL assemblies.
-When the native images are present, CoreCLR runtime will automatically use it instead of the original MSIL assemblies.
+You should include the native images in your app, either by replacing the original MSIL assemblies with the native images or by putting the native images next to the MSIL assemblies.
+When the native images are present, the CoreCLR runtime will automatically use it instead of the original MSIL assemblies.
 
 Common errors
 -------------
 
 The following are some of the command errors while creating or using native images:
 - "Error: Could not load file or assembly '...' or one of its dependencies. The system cannot find the file specified. (Exception from HRESULT: 0x80070002)": CrossGen wasn't able to find a particular dependency that it needs. Verify that you have the assembly specified in the error message, and make sure its location is included in `/Platform_Assemblies_Paths`.
 - CoreCLR unable to initialize: While there are many possible causes of this error, one possibility is a mismatch between System.Private.CoreLib.ni.dll and coreclr.dll (or libcoreclr.so). Make sure they come from the same build or NuGet package.
-- "Unable to load Jit Compiler": Please get a copy of `clrjit.dll` (or `libclrjit.so` or `libclrjit.dylib`, depending on your platform), and place it in the same directory as CrossGen (or use /JITPath option). You can either build `clrjit.dll` yourself, or get it from `Microsoft.NETCore.Jit` NuGet package. To avoid possible issues, please use `clrjit.dll` from the same build as `crossgen.exe` if possible.
+- "Unable to load Jit Compiler": Please get a copy of `clrjit.dll` (or `libclrjit.so` or `libclrjit.dylib`, depending on your platform), and place it in the same directory as CrossGen (or use /JITPath option). You can either build `clrjit.dll` yourself or get it from `Microsoft.NETCore.Jit` NuGet package. To avoid possible issues, please use `clrjit.dll` from the same build as `crossgen.exe` if possible.

Documentation/building/debugging-instructions.md

@@ -9,16 +9,16 @@ Debugging CoreCLR on Windows
 1. Perform a build of the repo.
 2. Open solution \<reporoot\>\bin\obj\Windows_NT.\<platform\>.\<configuration\>\CoreCLR.sln in Visual Studio. \<platform\> and \<configuration\> are based
     on type of build you did. By default they are 'x64' and 'Debug'.
-3. Right click the INSTALL project and choose ‘Set as StartUp Project’
+3. Right-click the INSTALL project and choose ‘Set as StartUp Project’
 4. Bring up the properties page for the INSTALL project
 5. Select Configuration Properties->Debugging from the left side tree control
 6. Set Command=`$(SolutionDir)..\..\product\Windows_NT.$(Platform).$(Configuration)\corerun.exe`
-	1. This points to the folder where the built runtime binaries are present.
+    1. This points to the folder where the built runtime binaries are present.
 7. Set Command Arguments=`<managed app you wish to run>` (e.g. HelloWorld.exe)
 8. Set Working Directory=`$(SolutionDir)..\..\product\Windows_NT.$(Platform).$(Configuration)`
-	1. This points to the folder containing CoreCLR binaries.
+    1. This points to the folder containing CoreCLR binaries.
 9. Press F11 to start debugging at wmain in corerun (or set a breakpoint in source and press F5 to run to it)
-	1. As an example, set a breakpoint for the EEStartup function in ceemain.cpp to break into CoreCLR startup.
+    1. As an example, set a breakpoint for the EEStartup function in ceemain.cpp to break into CoreCLR startup.
 
 Steps 1-8 only need to be done once, and then (9) can be repeated whenever you want to start debugging. The above can be done with Visual Studio 2013.
 
@@ -56,38 +56,38 @@ For .NET Core version 1.x and 2.0.x, libsosplugin.so is built for and will only
 
 ### SOS commands ###
 
-This is the full list of commands currently supported by SOS. lldb is case-sensitive unlike windbg.
-
-	Type "soshelp <functionname>" for detailed info on that function.
-
-	Object Inspection                  Examining code and stacks
-	-----------------------------      -----------------------------
-	DumpObj (dumpobj)                  Threads (clrthreads)
-	DumpArray                          ThreadState
-	DumpStackObjects (dso)             IP2MD (ip2md)
-	DumpHeap (dumpheap)                u (clru)
-	DumpVC                             DumpStack (dumpstack)
-	GCRoot (gcroot)                    EEStack (eestack)
-	PrintException (pe)                ClrStack (clrstack)
-	                                   GCInfo
-	                                   EHInfo
-	                                   bpmd (bpmd)
-
-	Examining CLR data structures      Diagnostic Utilities
-	-----------------------------      -----------------------------
-	DumpDomain                         VerifyHeap
-	EEHeap (eeheap)                    FindAppDomain
-	Name2EE (name2ee)                  DumpLog (dumplog)
-	DumpMT (dumpmt)                    CreateDump (createdump)
-	DumpClass (dumpclass)
-	DumpMD (dumpmd)
-	Token2EE
-	DumpModule (dumpmodule)
-	DumpAssembly
-	DumpRuntimeTypes
-	DumpIL (dumpil)
-	DumpSig
-	DumpSigElem
+This is the full list of commands currently supported by SOS. lldb is case-sensitive, unlike windbg.
+
+    Type "soshelp <functionname>" for detailed info on that function.
+
+    Object Inspection                  Examining code and stacks
+    -----------------------------      -----------------------------
+    DumpObj (dumpobj)                  Threads (clrthreads)
+    DumpArray                          ThreadState
+    DumpStackObjects (dso)             IP2MD (ip2md)
+    DumpHeap (dumpheap)                u (clru)
+    DumpVC                             DumpStack (dumpstack)
+    GCRoot (gcroot)                    EEStack (eestack)
+    PrintException (pe)                ClrStack (clrstack)
+                                       GCInfo
+                                       EHInfo
+                                       bpmd (bpmd)
+
+    Examining CLR data structures      Diagnostic Utilities
+    -----------------------------      -----------------------------
+    DumpDomain                         VerifyHeap
+    EEHeap (eeheap)                    FindAppDomain
+    Name2EE (name2ee)                  DumpLog (dumplog)
+    DumpMT (dumpmt)                    CreateDump (createdump)
+    DumpClass (dumpclass)
+    DumpMD (dumpmd)
+    Token2EE
+    DumpModule (dumpmodule)
+    DumpAssembly
+    DumpRuntimeTypes
+    DumpIL (dumpil)
+    DumpSig
+    DumpSigElem
 
     Examining the GC history           Other
     -----------------------------      -----------------------------
@@ -107,7 +107,7 @@ However the common commands have been aliased so that you don't need the SOS pre
     clrthreads      -> sos Threads
     clru            -> sos U
     createdump      -> sos CreateDump
-	dso             -> sos DumpStackObjects
+    dso             -> sos DumpStackObjects
     dumpclass       -> sos DumpClass
     dumpheap        -> sos DumpHeap
     dumpil          -> sos DumpIL
@@ -135,7 +135,7 @@ However the common commands have been aliased so that you don't need the SOS pre
 It is also possible to debug .NET Core crash dumps using lldb and SOS. In order to do this, you need all of the following:
 
 - The crash dump file. We have a service called "Dumpling" which collects, uploads, and archives crash dump files during all of our CI jobs and official builds.
-- On Linux, there is an utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy)) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
+- On Linux, there is a utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy)) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
 - To get matching runtime and symbol binaries for the core dump use the symbol downloader CLI extension:
   - Install the [.NET Core 2.1 SDK](https://www.microsoft.com/net/download/).
   - Install the symbol downloader extension: `dotnet tool install -g dotnet-symbol`. Make sure you are not in any project directory with a NuGet.Config that doesn't include nuget.org as a source. 
@@ -161,7 +161,7 @@ lldb-3.9 -O "settings set target.exec-search-paths <runtime-path>" -o "plugin lo
 - `<host-path>`: The path to the dotnet or corerun executable, potentially in the `<runtime-path>` folder.
 - `<path-to-libsosplugin.so>`: The path to libsosplugin.so, should be in the `<runtime-path>` folder.
 
-lldb should start debugging successfully at this point. You should see stacktraces with resolved symbols for libcoreclr.so. At this point, you can run `plugin load <libsosplugin.so-path>`, and begin using SOS commands, as above.
+lldb should start debugging successfully at this point. You should see stack traces with resolved symbols for libcoreclr.so. At this point, you can run `plugin load <libsosplugin.so-path>`, and begin using SOS commands, as above.
 
 ##### Example
 

Documentation/building/freebsd-instructions.md

@@ -239,7 +239,7 @@ If all works, you should be greeted by a friendly daemon you know well.
 
 Over time, this process will get easier. We will remove the dependency on having to compile managed code on Windows. For example, we are working to get our NuGet packages to include both the Windows and FreeBSD versions of an assembly, so you can simply nuget restore the dependencies. 
 
-A sample that builds Hello World on FreeBSD using the correct references but via XBuild or MonoDevelop would be great! Some of our processes (e.g. the System.Private.CoreLib build) rely on Windows specific tools, but we want to figure out how to solve these problems for FreeBSD as well. There's still a lot of work ahead, so if you're interested in helping, we're ready for you!
+A sample that builds Hello World on FreeBSD using the correct references but via XBuild or MonoDevelop would be great! Some of our processes (e.g. the System.Private.CoreLib build) rely on Windows-specific tools, but we want to figure out how to solve these problems for FreeBSD as well. There's still a lot of work ahead, so if you're interested in helping, we're ready for you!
 
 
 Run the test suite
@@ -279,7 +279,7 @@ llvm37 and llvm-devel include clang and lldb. Since clang is included with llvm
 
 After you have installed your desired version of LLVM you will need to specify the version to the build.sh script.
 
-For example if you chose to install llvm37 you would add the clangX.X to your build command as follows.
+For example, if you chose to install llvm37 you would add the clangX.X to your build command as follows.
 ```sh
 janhenke@freebsd-frankfurt:~/git/coreclr % ./build.sh clang3.7
 ```

Documentation/building/linux-instructions.md

@@ -132,7 +132,7 @@ The current Docker tag being used by the CI can be found in the `getDockerImageN
 
 Libunwind issue
 ---------------
-ARM libunwind versions before 1.3 require a fix. The fix allows libunwind not to break when it is ordered to access unaccessible memory locations. See [this](https://github.com/dotnet/coreclr/pull/3923) issue for history.
+ARM libunwind versions before 1.3 require a fix. The fix allows libunwind not to break when it is ordered to access inaccessible memory locations. See [this](https://github.com/dotnet/coreclr/pull/3923) issue for history.
 
 If required, first import the patch from the libunwind upstream: http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commit;h=770152268807e460184b4152e23aba9c86601090.
 
@@ -216,4 +216,3 @@ If you want to focus on the speed optimization for high-end devices, you have to
 
  SET (CLR_DEFINES_DEBUG_INIT              DEBUG _DEBUG _DBG URTBLDENV_FRIENDLY=Checked BUILDENV_
 ```
-

Documentation/building/test-configuration.md

@@ -38,7 +38,7 @@ Test cases are categorized by priority level. The most important subset should b
         // See the LICENSE file in the project root for more information.
     ```
 * Disable building of a test by conditionally setting the `<DisableProjectBuild>` property.
-	* e.g. `<DisableProjectBuild Condition=" '$(Platform)' == 'arm64' ">true</DisableProjectBuild>`
+    * e.g. `<DisableProjectBuild Condition=" '$(Platform)' == 'arm64' ">true</DisableProjectBuild>`
 * Exclude test from GCStress runs by adding the following to the csproj:
     * `<GCStressIncompatible>true</GCStressIncompatible>`
 * Exclude test from JIT stress runs runs by adding the following to the csproj:
@@ -59,7 +59,7 @@ Test cases are categorized by priority level. The most important subset should b
     * Not removing this can cause confusion with the way tests are generally handled behind the scenes by the build system.
 
 1. Set the `<CLRTestKind>`/`<CLRTestPriority>` properties.
-1. Add source files to new project.
+1. Add source files to the new project.
 1. Indicate the success of the test by returning `100`. Failure can be indicated by any non-`100` value.
 
     Example:

Documentation/building/testing-with-corefx.md

@@ -133,4 +133,4 @@ The tests defined in TopN.Windows.CoreFX.issues.json or the test list specified
             ]
         }
     }
-```
+```

Documentation/building/unix-test-instructions.md

@@ -40,7 +40,7 @@ Or
 
 For machines that have aarch64/armhf support, all the armhf packages will need to also be downloaded. Please note you will need to enable multiplatform support as well. Check with your distro provider or kernel options to see if this is supported. For simplicity, these instructions relate to aarch64 ubuntu enabling arm32 (hf) coreclr runs.
 
-Please make sure your device is running a 64 bit aarch64 kernel.
+Please make sure your device is running a 64-bit aarch64 kernel.
 
 ```
 # Example output
@@ -58,7 +58,7 @@ Linux tegra-ubuntu 4.4.38-tegra #1 SMP PREEMPT Thu Jul 20 00:41:06 PDT 2017 aarc
 [ubuntu:~]: sudo apt-get install libstdc++6:armhf
 ````
 
-At this point you should be able to run a 32-bit `corerun`. You can verify this by downloading and running a recently built arm32 coreclr.
+At this point, you should be able to run a 32-bit `corerun`. You can verify this by downloading and running a recently built arm32 coreclr.
 
 ```
 [ubuntu:~]: wget https://ci.dot.net/job/dotnet_coreclr/job/master/job/armlb_cross_checked_ubuntu/lastSuccessfulBuild/artifact/*zip*/archive.zip --no-check-certificate
@@ -113,7 +113,7 @@ In addition:
 <DisableProjectBuild Condition="'$(TargetsUnix)' == 'true'">true</DisableProjectBuild>
 ```
 
-Is used to disable the build, that way if building on unix cycles are saved building/running.
+Is used to disable the build, that way if building on Unix cycles are saved building/running.
 
 PAL tests
 ---------