Fix typos and grammar in compiler and build documentation

compiler/rustc_codegen_llvm/src/debuginfo/doc.md

@@ -16,7 +16,7 @@ module to generate correct metadata and insert it into the LLVM IR.
 As the exact format of metadata trees may change between different LLVM
 versions, we now use LLVM
 [DIBuilder](https://llvm.org/docs/doxygen/html/classllvm_1_1DIBuilder.html)
-to create metadata where possible. This will hopefully ease the adaption of
+to create metadata where possible. This will hopefully ease the adaptation of
 this module to future LLVM versions.
 
 The public API of the module is a set of functions that will insert the
@@ -87,19 +87,19 @@ describe the type anew. This behavior is encapsulated in the
 ## Source Locations and Line Information
 
 In addition to data type descriptions the debugging information must also
-allow to map machine code locations back to source code locations in order
+allow mapping machine code locations back to source code locations in order
 to be useful. This functionality is also handled in this module. The
-following functions allow to control source mappings:
+following functions allow controlling source mappings:
 
 + `set_source_location()`
 + `clear_source_location()`
 + `start_emitting_source_locations()`
 
-`set_source_location()` allows to set the current source location. All IR
+`set_source_location()` allows setting the current source location. All IR
 instructions created after a call to this function will be linked to the
 given source location, until another location is specified with
 `set_source_location()` or the source location is cleared with
-`clear_source_location()`. In the later case, subsequent IR instruction
+`clear_source_location()`. In the latter case, subsequent IR instructions
 will not be linked to any source location. As you can see, this is a
 stateful API (mimicking the one in LLVM), so be careful with source
 locations set by previous calls. It's probably best to not rely on any

compiler/rustc_thread_pool/src/sleep/README.md

@@ -32,7 +32,7 @@ There are three main thread states:
   waiting to be awoken.
 
 We sometimes refer to the final two states collectively as **inactive**.
-Threads begin as idle but transition to idle and finally sleeping when
+Threads begin as active but transition to idle and finally sleeping when
 they're unable to find work to do.
 
 ## Sleepy threads
@@ -160,7 +160,7 @@ not complete. It is possible -- if unlikely -- that enough activity occurs for
 Thread A to observe the same JEC value that it saw when getting sleepy. If the
 new work being published came from *inside* the thread-pool, then this race
 condition isn't too harmful. It means that we have fewer workers processing the
-work then we should, but we won't deadlock. This seems like an acceptable risk
+work than we should, but we won't deadlock. This seems like an acceptable risk
 given that this is unlikely in practice.
 
 However, if the work was posted as an *external* job, that is a problem. In that

src/bootstrap/README.md

@@ -175,8 +175,8 @@ When you use bootstrap, you'll call it through the entry point script
 (`x`, `x.ps1`, or `x.py`). However, most of the code lives in `src/bootstrap`.
 `bootstrap` has a difficult problem: it is written in Rust, but yet it is run
 before the Rust compiler is built! To work around this, there are two components
-of bootstrap: the main one written in rust, and `bootstrap.py`. `bootstrap.py`
-is what gets run by entry point script. It takes care of downloading the prebuilt
+of bootstrap: the main one written in Rust, and `bootstrap.py`. `bootstrap.py`
+is what gets run by the entry point script. It takes care of downloading the prebuilt
 stage 0 compiler, std and Cargo binaries, which are then used to build the
 bootstrap binary.
 

src/ci/docker/README.md

@@ -48,7 +48,7 @@ Refer to the [dev guide](https://rustc-dev-guide.rust-lang.org/tests/docker.html
 ## Docker Toolbox on Windows
 
 For Windows before Windows 10, the docker images can be run on Windows via
-[Docker Toolbox]. There are several preparation needs to be made before running
+[Docker Toolbox]. There are several preparations that need to be made before running
 a Docker image.
 
 1. Stop the virtual machine from the terminal with `docker-machine stop`
@@ -92,7 +92,7 @@ To run the image,
 A number of these images take quite a long time to compile as they're building
 whole gcc toolchains to do cross builds with. Much of this is relatively
 self-explanatory but some images use [crosstool-ng] which isn't quite as self
-explanatory. Below is a description of where these `*.defconfig` files come form,
+explanatory. Below is a description of where these `*.defconfig` files come from,
 how to generate them, and how the existing ones were generated.
 
 [crosstool-ng]: https://github.com/crosstool-ng/crosstool-ng