issue-130 incorporate the review comments

Author: Rajkumar Natarajan

src/SUMMARY.md

@@ -3,6 +3,8 @@
 - [About this guide](./about-this-guide.md)
 - [About the compiler team](./compiler-team.md)
 - [How to build the compiler and run what you built](./how-to-build-and-run.md)
+    - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md)
+    - [Documenting Compiler](./compiler-documenting.md)
 - [Coding conventions](./conventions.md)
 - [Walkthrough: a typical contribution](./walkthrough.md)
 - [The compiler testing framework](./tests/intro.md)

src/build-install-distribution-artifacts.md

@@ -3,15 +3,17 @@
 You might want to build and package up the compiler for distribution.
 You’ll want to run this command to do it:
 
-   `./x.py dist`
+   ```bash
+   ./x.py dist
+   ```
 
-Other Flags
+## Other Flags
 
 The same flags from build are available here. 
 You might want to consider adding on the -j flag for faster builds 
 when building a distribution artifact.
 
-```
+```bash
 -j, --jobs JOBS     number of jobs to run in parallel
 ```
 
@@ -21,7 +23,6 @@ when building a distribution artifact.
 If you’ve built a distribution artifact you might want to install it and 
 test that it works on your target system. You’ll want to run this command:
 
-   `./x.py install`
-
-Other Flags
-The same flags from build are available 
+   ```bash
+   ./x.py install
+   ``` 

src/compiler-documenting.md

@@ -3,17 +3,21 @@
 You might want to build documentation of the various components 
 available like the standard library. There’s two ways to go about this.
  You can run rustdoc directly on the file to make sure the HTML is 
- correct which is fast or you can build the documentation as part of the 
- build process through x.py. Both are viable methods since documentation 
- is more about the content.
+ correct, which is fast. Alternatively, you can build the documentation 
+ as part of the  build process through x.py. Both are viable methods 
+ since documentation  is more about the content.
 
 ## Document everything
 
-   `./x.py doc`
+   ```bash
+   ./x.py doc
+   ```
 
 ## If you want to avoid the whole Stage 2 build
 
-   `./x.py doc --stage 1`
+```bash
+./x.py doc --stage 1
+```
 
 First the compiler and rustdoc get built to make sure everything is okay 
 and then it documents the files.
@@ -35,15 +39,22 @@ Mostly because this is useless for the average user. However, you might need
 to have it available so you can understand the types. Here’s how you can 
 compile it yourself. From the top level directory where x.py is located run:
 
-    cp config.toml.example config.toml
+```bash
+cp config.toml.example config.toml
+```
 
 Next open up config.toml and make sure these two lines are set to true:
 
+```bash
 docs = true
 compiler-docs = true
+```
+
 When you want to build the compiler docs as well run this command:
 
-   `./x.py doc`
+```bash
+./x.py doc
+```
 
 This will see that the docs and compiler-docs options are set to true 
 and build the normally hidden compiler docs!

src/how-to-build-and-run.md

@@ -47,6 +47,14 @@ debuginfo-lines = true
 use-jemalloc = false
 ```
 
+### what is x.py?
+
+x.py is the script used to orchestrate the tooling in the rustc repository. 
+It is the script that can build docs, run tests, and compile rustc. 
+It is the now preferred way to build rustc and it replaces the old makefiles 
+from before. Below are the different ways to utilize x.py in order to 
+effectively deal with the repo for various common tasks.
+
 ### Running x.py and building a stage1 compiler
 
 One thing to keep in mind is that `rustc` is a _bootstrapping_
@@ -80,6 +88,52 @@ compiling `rustc` is done in stages:
   can build the libraries with the stage2 compiler. The result ought
   to be identical to before, unless something has broken.
 
+
+#### Build Flags
+
+There are other flags you can pass to the build portion of x.py that can be 
+beneficial to cutting down compile times or fitting other things you might 
+need to change. They are:
+
+```bash
+Options:
+    -v, --verbose       use verbose output (-vv for very verbose)
+    -i, --incremental   use incremental compilation
+        --config FILE   TOML configuration file for build
+        --build BUILD   build target of the stage0 compiler
+        --host HOST     host targets to build
+        --target TARGET target targets to build
+        --on-fail CMD   command to run on failure
+        --stage N       stage to build
+        --keep-stage N  stage to keep without recompiling
+        --src DIR       path to the root of the rust checkout
+    -j, --jobs JOBS     number of jobs to run in parallel
+    -h, --help          print this help message
+```
+
+One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That
+is, since `rustc` is written in Rust, we need to use an older version of the
+compiler to compile the newer version. In particular, the newer version of the
+compiler, `libstd`, and other tooling may use some unstable features
+internally. The result is the compiling `rustc` is done in stages.
+
+- **Stage 0:** the stage0 compiler can be your existing
+  (perhaps older version of)
+  Rust compiler, the current _beta_ compiler or you may download the binary
+  from the internet.
+- **Stage 1:** the code in your clone (for new version)
+  is then compiled with the stage0
+  compiler to produce the stage1 compiler.
+  However, it was built with an older compiler (stage0),
+  so to optimize the stage1 compiler we go to next stage.
+- **Stage 2:** we rebuild our stage1 compiler with itself
+  to produce the stage2 compiler (i.e. it builds
+  itself) to have all the _latest optimizations_.
+- _(Optional)_ **Stage 3**: to sanity check of our new compiler,
+  we can build it again
+  with stage2 compiler which must be identical to itself,
+  unless something has broken.
+
 For hacking, often building the stage 1 compiler is enough, but for
 final testing and release, the stage 2 compiler is used.
 
@@ -134,37 +188,25 @@ build`) has quite a few more steps:
 
 <a name=toolchain></a>
 
-### Build different stages
-
-  `./x.py build --stage 0`
-
-  # Stage 1 is typically enough to test out all of your changes
-  # to the compiler
-    
-  `./x.py build --stage 1`
-
-  # Equivalent to ./x.py build
-    
-  `./x.py build --stage 2`
-
-You can pass the --stage flag with what stage you want to build to. 
-It is recommended that you build to Stage 1 as this is enough to know 
-your changes can successfully compile and should let you run tests 
-with your changes.
-
 ### Build specific components
 
    Build only the libcore library
 
-   `./x.py build src/libcore`
+```bash
+> ./x.py build src/libcore
+```
 
    Build the libcore and libproc_macro library only
 
-   `./x.py build src/libcore src/libproc_macro`
+```bash
+> ./x.py build src/libcore src/libproc_macro
+```
 
    Build only libcore up to Stage 1
 
-   `./x.py build src/libcore --stage 1`
+```bash
+> ./x.py build src/libcore --stage 1
+```
 
 Sometimes you might just want to test if the part you’re working on can 
 compile. Using these commands you can test that it compiles before doing 
@@ -183,8 +225,8 @@ you will likely need to build at some point; for example, if you want
 to run the entire test suite).
 
 ```bash
-  rustup toolchain link stage1 build/<host-triple>/stage1
-  rustup toolchain link stage2 build/<host-triple>/stage2
+> rustup toolchain link stage1 build/<host-triple>/stage1
+> rustup toolchain link stage2 build/<host-triple>/stage2
 ```
 
 The `<host-triple>` would typically be one of the following:
@@ -309,4 +351,6 @@ If you need to run this then rustbuild is most likely not acting right and
 you should file a bug as to what is going wrong. If you do need to clean 
 everything up then you only need to run one command!
 
-   `./x.py clean`
+   ```bash
+   > ./x.py clean
+   ```

src/tests/running.md

@@ -93,23 +93,21 @@ This is much faster, but doesn't always work. For example, some tests
 include directives that specify specific compiler flags, or which rely
 on other crates, and they may not run the same without those options.
 
-### Run specific tests
-
-# Run only the tidy script
+### Run only the tidy script
 ```bash
 > ./x.py test src/tools/tidy
 ```
-# Run tests on the standard library
+### Run tests on the standard library
 ```bash
 > ./x.py test src/libstd
 ```
 
-# Run tests on the standard library and run the tidy script
+### Run tests on the standard library and run the tidy script
 ```bash
 > ./x.py test src/libstd src/tools/tidy
 ```
 
-# Run tests on the standard library using a stage 1 compiler
+### Run tests on the standard library using a stage 1 compiler
 ```bash
 >   ./x.py test src/libstd --stage 1
 ```