Replace `$TARGET` with `host`

This avoids having to manually modify the configuration in the docs.

src/building/suggested.md

@@ -34,10 +34,10 @@ you can write: <!-- date-check: nov 2022 --><!-- the date comment is for the edi
         "--json-output"
     ],
     "rust-analyzer.rustfmt.overrideCommand": [
-        "./build/$TARGET_TRIPLE/stage0/bin/rustfmt",
+        "./build/host/stage0/bin/rustfmt",
         "--edition=2021"
     ],
-    "rust-analyzer.procMacro.server": "./build/$TARGET_TRIPLE/stage0/libexec/rust-analyzer-proc-macro-srv",
+    "rust-analyzer.procMacro.server": "./build/host/stage0/libexec/rust-analyzer-proc-macro-srv",
     "rust-analyzer.procMacro.enable": true,
     "rust-analyzer.cargo.buildScripts.enable": true,
     "rust-analyzer.cargo.buildScripts.invocationLocation": "root",
@@ -48,7 +48,7 @@ you can write: <!-- date-check: nov 2022 --><!-- the date comment is for the edi
         "check",
         "--json-output"
     ],
-    "rust-analyzer.cargo.sysroot": "./build/$TARGET_TRIPLE/stage0-sysroot",
+    "rust-analyzer.cargo.sysroot": "./build/host/stage0-sysroot",
     "rust-analyzer.rustc.source": "./Cargo.toml",
 }
 ```
@@ -56,11 +56,6 @@ you can write: <!-- date-check: nov 2022 --><!-- the date comment is for the edi
 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.
 
-> NOTE: Make sure to replace `TARGET_TRIPLE` in the `rust-analyzer.rustfmt.overrideCommand`
-> setting with the appropriate target triple for your machine. An example of such
-> a triple is `x86_64-unknown-linux-gnu`. An easy way to check your target triple
-> is to run `rustc -vV` and checking the `host` value of its output.
-
 If you have enough free disk space and you would like to be able to run `x.py` commands while
 rust-analyzer runs in the background, you can also add `--build-dir build-rust-analyzer` to the
 `overrideCommand` to avoid x.py locking.

src/contributing.md

@@ -348,7 +348,7 @@ the entire stage 2 compiler and compile the various books published on
 [doc.rust-lang.org][docs]. When updating documentation for the standard library,
 first try `./x.py doc library`. If that fails, or if you need to
 see the output from the latest version of `rustdoc`, add `--stage 1`.
-Results should appear in `build/$TARGET/doc`.
+Results should appear in `build/host/doc`.
 
 [docs]: https://doc.rust-lang.org
 

src/rustdoc.md

@@ -46,15 +46,15 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
 * Use `./x.py build` to make a usable
   rustdoc you can run on other projects.
   * Add `library/test` to be able to use `rustdoc --test`.
-  * Run `rustup toolchain link stage2 build/$TARGET/stage2` to add a
+  * Run `rustup toolchain link stage2 build/host/stage2` to add a
     custom toolchain called `stage2` to your rustup environment. After
     running that, `cargo +stage2 doc` in any directory will build with
     your locally-compiled rustdoc.
 * Use `./x.py doc library` to use this rustdoc to generate the
   standard library docs.
-  * The completed docs will be available in `build/$TARGET/doc` (under `core`, `alloc`, and `std`).
+  * The completed docs will be available in `build/host/doc` (under `core`, `alloc`, and `std`).
   * If you want to copy those docs to a webserver, copy all of
-    `build/$TARGET/doc`, since that's where the CSS, JS, fonts, and landing
+    `build/host/doc`, since that's where the CSS, JS, fonts, and landing
     page are.
 * Use `./x.py test src/test/rustdoc*` to run the tests using a stage1
   rustdoc.

src/tests/running.md

@@ -242,7 +242,7 @@ machine, e.g. for RISC-V
 ```
 
 The binary will be created at
-`./build/$HOST_ARCH/stage2-tools/$TARGET_ARCH/release/remote-test-server`. Copy
+`./build/host/stage2-tools/$TARGET_ARCH/release/remote-test-server`. Copy
 this over to the remote machine.
 
 On the remote machine, run the `remote-test-server` with the `--bind