Apply suggestions from code review

Co-authored-by: mark-i-m <mark-i-m@users.noreply.github.com>
Co-authored-by: spastorino <spastorino@gmail.com>

Author: 3 people

src/building/suggested.md

@@ -3,10 +3,10 @@
 The full bootstrapping process takes quite a while. Here are five suggestions
 to make your life easier.
 
-## Configuring `rust-analyser` for `rustc`
+## Configuring `rust-analyzer` for `rustc`
 
-`rust-analyser` can help you check and format your code whenever you save
-a file. By default, `rust-analyser` runs the `cargo check` and `rustfmt`
+`rust-analyzer` can help you check and format your code whenever you save
+a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt`
 commands, but you can override these commands to use more adapted versions
 of these tools when hacking on `rustc`. For example, for Visual Studio Code,
 you can write:
@@ -25,13 +25,13 @@ you can write:
 }
 ```
 
-in your `.vscode/settings.json` file. This will ask `rust-analyser` to use
+in your `.vscode/settings.json` file. This will ask `rust-analyzer` to use
 `x.py check` to check the sources, and the stage 0 rustfmt to format them.
 
 ## Check, check, and check again
 
 When doing simple refactorings, it can be useful to run `./x.py check`
-continuously. If you set up `rust-analyser` as described above, this will
+continuously. If you set up `rust-analyzer` as described above, this will
 be done for you every time you save a file. Here you are just checking that
 the compiler can **build**, but often that is all you need (e.g., when renaming a
 method). You can then run `./x.py build` when you actually need to
@@ -94,8 +94,15 @@ building the compiler on one branch will cause the old build and the
 incremental compilation cache to be overwritten. One solution would be
 to have multiple clones of the repository, but that would mean storing the
 Git metadata multiple times, and having to update each clone individually.
+
 Fortunately, Git has a better solution called [worktrees]. This lets you
 create multiple "working trees", which all share the same Git database.
+Moreover, because all of the worktrees share the same object database,
+if you update a branch (e.g. master) in any of them, you can use the new
+commits from any of the worktrees. One caveat, though, is that submodules
+do not get shared. They will still be cloned multiple times.
+
+[worktrees]: https://git-scm.com/docs/git-worktree
 
 Given you are inside the root directory for your rust repository, you can
 create a "linked working tree" in a new "rust2" directory by running
@@ -114,8 +121,6 @@ git worktree add -b my-feature ../rust2 master
 You can then use that rust2 folder as a separate workspace for modifying
 and building `rustc`!
 
-[worktrees]: https://git-scm.com/docs/git-worktree
-
 ## Building with system LLVM
 
 By default, LLVM is built from source, and that can take significant amount of