Merge from rustc

src/SUMMARY.md

@@ -75,6 +75,7 @@
 - [Prologue](./building/bootstrapping/intro.md)
 - [What Bootstrapping does](./building/bootstrapping/what-bootstrapping-does.md)
 - [How Bootstrap does it](./building/bootstrapping/how-bootstrap-does-it.md)
+- [Writing tools in Bootstrap](./building/bootstrapping/writing-tools-in-bootstrap.md)
 - [Debugging bootstrap](./building/bootstrapping/debugging-bootstrap.md)
 
 # High-level Compiler Architecture

src/building/bootstrapping/writing-tools-in-bootstrap.md

@@ -0,0 +1,23 @@
+# Writing tools in Bootstrap
+
+There are three types of tools you can write in bootstrap:
+
+- **`Mode::ToolBootstrap`**
+  Use this for tools that don’t need anything from the in-tree compiler and can run with the stage0 `rustc`.
+  The output is placed in the "stage0-bootstrap-tools" directory. This mode is for general-purpose tools built
+  entirely with the stage0 compiler, including target libraries and only works for stage 0.
+
+- **`Mode::ToolStd`**
+  Use this for tools that rely on the locally built std. The output goes into the "stageN-tools" directory.
+  This mode is rarely used, mainly for `compiletest` which requires `libtest`.
+
+- **`Mode::ToolRustc`**
+  Use this for tools that depend on both the locally built `rustc` and the target `std`. This is more complex than
+  the other modes because the tool must be built with the same compiler used for `rustc` and placed in the "stageN-tools"
+  directory. When you choose `Mode::ToolRustc`, `ToolBuild` implementation takes care of this automatically.
+  If you need to use the builder’s compiler for something specific, you can get it from `ToolBuildResult`, which is
+  returned by the tool's [`Step`].
+
+Regardless of the tool type you must return `ToolBuildResult` from the tool’s [`Step`] implementation and use `ToolBuild` inside it.
+
+[`Step`]: https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/trait.Step.html

src/building/suggested.md

@@ -154,6 +154,16 @@ You can run `./x setup editor` and select `helix`, which will prompt you to
 create `languages.toml` with the recommended configuration for Helix. The
 recommended settings live at [`src/etc/rust_analyzer_helix.toml`].
 
+### Zed
+
+Zed comes with built-in LSP and rust-analyzer support.
+It can be configured through `.zed/settings.json`, as described
+[here](https://zed.dev/docs/configuring-languages). Selecting `zed`
+in `./x setup editor` will prompt you to create a `.zed/settings.json`
+file which will configure Zed with the recommended configuration. The
+recommended `rust-analyzer` settings live
+at [`src/etc/rust_analyzer_zed.json`].
+
 ## Check, check, and check again
 
 When doing simple refactoring, it can be useful to run `./x check`
@@ -381,4 +391,5 @@ load this completion.
 [`src/etc/rust_analyzer_settings.json`]: https://github.com/rust-lang/rust/blob/master/src/etc/rust_analyzer_settings.json
 [`src/etc/rust_analyzer_eglot.el`]: https://github.com/rust-lang/rust/blob/master/src/etc/rust_analyzer_eglot.el
 [`src/etc/rust_analyzer_helix.toml`]: https://github.com/rust-lang/rust/blob/master/src/etc/rust_analyzer_helix.toml
+[`src/etc/rust_analyzer_zed.json`]: https://github.com/rust-lang/rust/blob/master/src/etc/rust_analyzer_zed.json
 [`src/etc/pre-push.sh`]: https://github.com/rust-lang/rust/blob/master/src/etc/pre-push.sh

src/implementing_new_features.md

@@ -167,9 +167,7 @@ a new unstable feature:
 
 1. Prevent usage of the new feature unless the feature gate is set.
    You can check it in most places in the compiler using the
-   expression `tcx.features().$feature_name` (or
-   `sess.features_untracked().$feature_name` if the
-   tcx is unavailable)
+   expression `tcx.features().$feature_name()`
 
     If the feature gate is not set, you should either maintain
     the pre-feature behavior or raise an error, depending on