update the bootstrap readme

Author: Shourya742

src/bootstrap/README.md

@@ -28,14 +28,14 @@ compiler. What actually happens when you invoke bootstrap is:
    `x.py` cross-platform) is run. This script is responsible for downloading the stage0
    compiler/Cargo binaries, and it then 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 (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
-   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
-   artifacts are generated using that compiler.
+2. In Rust, the bootstrap binary reads all configuration, performs a number of sanity
+   checks (for example, verifying toolchains and paths), and then prepares to build the
+   stage 1 compiler and libraries using the prebuilt stage 0 compiler.
+3. The stage 0 compiler and standard library, downloaded earlier, are used to build the
+   stage 1 compiler, which links against the beta standard library. The newly built stage 1
+   compiler is then used to build the stage 1 standard library. After that, the stage 1
+   compiler is used once more to produce the stage 2 compiler, which links against the
+   stage 1 standard library.
 
 The goal of each stage is to (a) leverage Cargo as much as possible and failing
 that (b) leverage Rust as much as possible!
@@ -120,44 +120,12 @@ build/
       debuginfo/
       ...
 
-    # Host tools (which are always compiled with the stage0 compiler)
-    # are stored here.
-    bootstrap-tools/
-
     # 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 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, the test system, the compiler, and various tools,
-    # 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 that these are filled in correctly.
-    stageN-std/
-    stageN-test/
-    stageN-rustc/
-    stageN-tools/
-
-    # This is a special case of the above directories, **not** filled in via
-    # Cargo but rather the build system itself. The stage0 compiler already has
-    # a set of target libraries for its own host triple (in its own sysroot)
-    # inside of stage0/. When we run the stage0 compiler to bootstrap more
-    # things, however, we don't want to use any of these libraries (as those are
-    # the ones that we're building). So essentially, when the stage1 compiler is
-    # 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 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/
-
     # These output directories are intended to be standalone working
     # implementations of the compiler (corresponding to each stage). The build
     # system will link (using hard links) output from stageN-{std,rustc} into
@@ -167,7 +135,6 @@ build/
     # no extra build output in these directories.
     stage1/
     stage2/
-    stage3/
 ```
 
 ## Extending bootstrap
@@ -177,8 +144,9 @@ When you use bootstrap, you'll call it through the entry point script
 `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 `stage0`
-compiler, which will then build the bootstrap binary written in Rust.
+is what gets run by 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.
 
 Because there are two separate codebases behind `x.py`, they need to
 be kept in sync. In particular, both `bootstrap.py` and the bootstrap binary