Rollup merge of #102604 - anirudh24seven:anirudh_improve_bootrap_readme_readability, r=Mark-Simulacrum

Improve readability of bootstrap's README

Improve readability of bootstrap's README by adding commas & minor changes

Author: matthiaskrgr

src/bootstrap/README.md

@@ -1,7 +1,7 @@
 # rustbuild - Bootstrapping Rust
 
 This is an in-progress README which is targeted at helping to explain how Rust
-is bootstrapped and in general some of the technical details of the build
+is bootstrapped and in general, some of the technical details of the build
 system.
 
 ## Using rustbuild
@@ -12,16 +12,16 @@ The rustbuild build system has a primary entry point, a top level `x.py` script:
 $ python ./x.py build
 ```
 
-Note that if you're on Unix you should be able to execute the script directly:
+Note that if you're on Unix, you should be able to execute the script directly:
 
 ```sh
 $ ./x.py build
 ```
 
 The script accepts commands, flags, and arguments to determine what to do:
 
-* `build` - a general purpose command for compiling code. Alone `build` will
-  bootstrap the entire compiler, and otherwise arguments passed indicate what to
+* `build` - a general purpose command for compiling code. Alone, `build` will
+  bootstrap the entire compiler, and otherwise, arguments passed indicate what to
   build. For example:
 
   ```
@@ -38,7 +38,7 @@ The script accepts commands, flags, and arguments to determine what to do:
   ./x.py build --stage 0 library/test
   ```
 
-  If files are dirty that would normally be rebuilt from stage 0, that can be
+  If files that would normally be rebuilt from stage 0 are dirty, the rebuild can be
   overridden using `--keep-stage 0`. Using `--keep-stage n` will skip all steps
   that belong to stage n or earlier:
 
@@ -47,8 +47,8 @@ The script accepts commands, flags, and arguments to determine what to do:
   ./x.py build --keep-stage 0
   ```
 
-* `test` - a command for executing unit tests. Like the `build` command this
-  will execute the entire test suite by default, and otherwise it can be used to
+* `test` - a command for executing unit tests. Like the `build` command, this
+  will execute the entire test suite by default, and otherwise, it can be used to
   select which test suite is run:
 
   ```
@@ -75,7 +75,7 @@ The script accepts commands, flags, and arguments to determine what to do:
   ./x.py test src/doc
   ```
 
-* `doc` - a command for building documentation. Like above can take arguments
+* `doc` - a command for building documentation. Like above, can take arguments
   for what to document.
 
 ## Configuring rustbuild
@@ -110,12 +110,12 @@ compiler. What actually happens when you invoke rustbuild is:
    compiles the build system itself (this folder). Finally, it then invokes the
    actual `bootstrap` binary build system.
 2. In Rust, `bootstrap` will slurp up all configuration, perform a number of
-   sanity checks (compilers exist for example), and then start building the
+   sanity checks (whether compilers exist, for example), and then start building the
    stage0 artifacts.
-3. The stage0 `cargo` downloaded earlier is used to build the standard library
+3. The stage0 `cargo`, downloaded earlier, is used to build the standard library
    and the compiler, and then these binaries are then copied to the `stage1`
    directory. That compiler is then used to generate the stage1 artifacts which
-   are then copied to the stage2 directory, and then finally the stage2
+   are then copied to the stage2 directory, and then finally, the stage2
    artifacts are generated using that compiler.
 
 The goal of each stage is to (a) leverage Cargo as much as possible and failing
@@ -149,7 +149,7 @@ like this:
 build/
 
   # Location where the stage0 compiler downloads are all cached. This directory
-  # only contains the tarballs themselves as they're extracted elsewhere.
+  # only contains the tarballs themselves, as they're extracted elsewhere.
   cache/
     2015-12-19/
     2016-01-15/
@@ -172,22 +172,22 @@ build/
   # hand.
   x86_64-unknown-linux-gnu/
 
-    # The build artifacts for the `compiler-rt` library for the target this
-    # folder is under. The exact layout here will likely depend on the platform,
-    # and this is also built with CMake so the build system is also likely
-    # different.
+    # The build artifacts for the `compiler-rt` library for the target that
+    # this folder is under. The exact layout here will likely depend on the
+    # platform, and this is also built with CMake, so the build system is
+    # also likely different.
     compiler-rt/
       build/
 
     # Output folder for LLVM if it is compiled for this target
     llvm/
 
       # build folder (e.g. the platform-specific build system). Like with
-      # compiler-rt this is compiled with CMake
+      # compiler-rt, this is compiled with CMake
       build/
 
       # Installation of LLVM. Note that we run the equivalent of 'make install'
-      # for LLVM to setup these folders.
+      # for LLVM, to setup these folders.
       bin/
       lib/
       include/
@@ -206,18 +206,18 @@ build/
 
     # Location where the stage0 Cargo and Rust compiler are unpacked. This
     # directory is purely an extracted and overlaid tarball of these two (done
-    # by the bootstrapy python script). In theory the build system does not
+    # by the bootstrap python script). In theory, the build system does not
     # modify anything under this directory afterwards.
     stage0/
 
-    # These to build directories are the cargo output directories for builds of
-    # the standard library and compiler, respectively. Internally these may also
+    # These to-build directories are the cargo output directories for builds of
+    # the standard library and compiler, respectively. Internally, these may also
     # have other target directories, which represent artifacts being compiled
     # from the host to the specified target.
     #
     # Essentially, each of these directories is filled in by one `cargo`
     # invocation. The build system instruments calling Cargo in the right order
-    # with the right variables to ensure these are filled in correctly.
+    # with the right variables to ensure that these are filled in correctly.
     stageN-std/
     stageN-test/
     stageN-rustc/
@@ -232,8 +232,8 @@ build/
     # being compiled (e.g. after libstd has been built), *this* is used as the
     # sysroot for the stage0 compiler being run.
     #
-    # Basically this directory is just a temporary artifact use to configure the
-    # stage0 compiler to ensure that the libstd we just built is used to
+    # Basically, this directory is just a temporary artifact used to configure the
+    # stage0 compiler to ensure that the libstd that we just built is used to
     # compile the stage1 compiler.
     stage0-sysroot/lib/
 
@@ -242,7 +242,7 @@ build/
     # system will link (using hard links) output from stageN-{std,rustc} into
     # each of these directories.
     #
-    # In theory there is no extra build output in these directories.
+    # In theory, there is no extra build output in these directories.
     stage1/
     stage2/
     stage3/
@@ -265,14 +265,14 @@ structure here serves two goals:
    depend on `std`, so libstd is a separate project compiled ahead of time
    before the actual compiler builds.
 2. Splitting "host artifacts" from "target artifacts". That is, when building
-   code for an arbitrary target you don't need the entire compiler, but you'll
+   code for an arbitrary target, you don't need the entire compiler, but you'll
    end up needing libraries like libtest that depend on std but also want to use
    crates.io dependencies. Hence, libtest is split out as its own project that
    is sequenced after `std` but before `rustc`. This project is built for all
    targets.
 
 There is some loss in build parallelism here because libtest can be compiled in
-parallel with a number of rustc artifacts, but in theory the loss isn't too bad!
+parallel with a number of rustc artifacts, but in theory, the loss isn't too bad!
 
 ## Build tools
 
@@ -285,13 +285,13 @@ appropriate libstd/libtest/librustc compile above.
 
 ## Extending rustbuild
 
-So you'd like to add a feature to the rustbuild build system or just fix a bug.
+So, you'd like to add a feature to the rustbuild build system or just fix a bug.
 Great! One of the major motivational factors for moving away from `make` is that
 Rust is in theory much easier to read, modify, and write. If you find anything
-excessively confusing, please open an issue on this and we'll try to get it
-documented or simplified pronto.
+excessively confusing, please open an issue on this, and we'll try to get it
+documented or simplified, pronto.
 
-First up, you'll probably want to read over the documentation above as that'll
+First up, you'll probably want to read over the documentation above, as that'll
 give you a high level overview of what rustbuild is doing. You also probably
 want to play around a bit yourself by just getting it up and running before you
 dive too much into the actual build system itself.
@@ -326,7 +326,7 @@ A 'major change' includes
 Changes that do not affect contributors to the compiler or users
 building rustc from source don't need an update to `VERSION`.
 
-If you have any questions feel free to reach out on the `#t-infra` channel in
+If you have any questions, feel free to reach out on the `#t-infra` channel in
 the [Rust Zulip server][rust-zulip] or ask on internals.rust-lang.org. When
 you encounter bugs, please file issues on the rust-lang/rust issue tracker.