From 0d7475b1393dc6a3e81fc6b2e8bf4b30a5449e8f Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 15:52:02 +0200 Subject: [PATCH 01/12] that made table much too wide Made it easy to miss the last column --- src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 1808a8e000..351be5e39f 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -23,7 +23,7 @@ Item | Kind | Short description | Chapter | `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [compiler/rustc_span/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [compiler/rustc_span/src/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [compiler/rustc_span/src/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) -`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) +`TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [compiler/rustc_middle/src/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [compiler/rustc_middle/src/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html) From 6d5e3347c53746c990580930a7a03d211c11a95e Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 16:50:34 +0200 Subject: [PATCH 02/12] "*. does not indicate a list element --- ci/sembr/src/main.rs | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ci/sembr/src/main.rs b/ci/sembr/src/main.rs index 742671ee7b..2d7fd26023 100644 --- a/ci/sembr/src/main.rs +++ b/ci/sembr/src/main.rs @@ -24,7 +24,7 @@ static REGEX_IGNORE_END: LazyLock = static REGEX_IGNORE_LINK_TARGETS: LazyLock = LazyLock::new(|| Regex::new(r"^\[.+\]: ").unwrap()); static REGEX_SPLIT: LazyLock = - LazyLock::new(|| Regex::new(r"([^\.\d\-\*]\.|[^r\~]\?|!)\s").unwrap()); + LazyLock::new(|| Regex::new(r"([^\.\d\-]\.|[^r\~]\?|!)\s").unwrap()); // list elements, numbered (1.) or not (- and *) static REGEX_LIST_ENTRY: LazyLock = LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*|\d\))\s+").unwrap()); @@ -385,7 +385,6 @@ encountering a cycle doesn't mean that we would get an infinite proof tree. } #[test] -#[ignore] fn should_split() { let original = "the queries that we do, as well as the **query DAG**. The"; let expected = "the queries that we do, as well as the **query DAG**.\nThe\n"; From 28d3215a962c8711485a9f6bd43369e81341e68b Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 16:51:35 +0200 Subject: [PATCH 03/12] sembr src/ty-fold.md --- src/ty-fold.md | 65 ++++++++++++++++++++++++++++---------------------- 1 file changed, 36 insertions(+), 29 deletions(-) diff --git a/src/ty-fold.md b/src/ty-fold.md index bf0a51e6b7..66dfc648e9 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -7,13 +7,11 @@ to find any usages of the bound vars in order to replace them. Binders can wrap an arbitrary Rust type `T`, not just a `Ty`. So, how do we implement the `instantiate` methods on the `Early/Binder` types? -The answer is a couple of traits: -[`TypeFoldable`] -and -[`TypeFolder`]. +The answer is a couple of traits: [`TypeFoldable`] +and [`TypeFolder`]. -- `TypeFoldable` is implemented by types that embed type information. It allows you to recursively - process the contents of the `TypeFoldable` and do stuff to them. +- `TypeFoldable` is implemented by types that embed type information. + It allows you to recursively process the contents of the `TypeFoldable` and do stuff to them. - `TypeFolder` defines what you want to do with the types you encounter while processing the `TypeFoldable`. @@ -38,8 +36,10 @@ So to reiterate: In the case of `subst`, we can see that it is implemented as a `TypeFolder`: [`ArgFolder`]. Looking at its implementation, we see where the actual substitutions are happening. -However, you might also notice that the implementation calls this `super_fold_with` method. What is -that? It is a method of `TypeFoldable`. Consider the following `TypeFoldable` type `MyFoldable`: +However, you might also notice that the implementation calls this `super_fold_with` method. +What is that? +It is a method of `TypeFoldable`. +Consider the following `TypeFoldable` type `MyFoldable`: ```rust,ignore struct MyFoldable<'tcx> { @@ -49,12 +49,13 @@ struct MyFoldable<'tcx> { ``` The `TypeFolder` can call `super_fold_with` on `MyFoldable` if it just wants to replace some of the -fields of `MyFoldable` with new values. If it instead wants to replace the whole `MyFoldable` with a -different one, it would call `fold_with` instead (a different method on `TypeFoldable`). +fields of `MyFoldable` with new values. +If it instead wants to replace the whole `MyFoldable` with a different one, +it would call `fold_with` instead (a different method on `TypeFoldable`). In almost all cases, we don’t want to replace the whole struct; we only want to replace `ty::Ty`s in -the struct, so usually we call `super_fold_with`. A typical implementation that `MyFoldable` could -have might do something like this: +the struct, so usually we call `super_fold_with`. +A typical implementation that `MyFoldable` could have might do something like this: ```rust,ignore my_foldable: MyFoldable<'tcx> @@ -72,24 +73,30 @@ impl TypeFoldable for MyFoldable { } ``` -Notice that here, we implement `super_fold_with` to go over the fields of `MyFoldable` and call -`fold_with` on *them*. That is, a folder may replace `def_id` and `ty`, but not the whole -`MyFoldable` struct. - -Here is another example to put things together: suppose we have a type like `Vec>`. The -`ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. If we want to do `subst(X => u32)`, -then we would first look at the overall type. We would see that there are no substitutions to be -made at the outer level, so we would descend one level and look at `Adt(Vec, &[Param(X)])`. There -are still no substitutions to be made here, so we would descend again. Now we are looking at -`Param(X)`, which can be substituted, so we replace it with `u32`. We can’t descend any more, so we -are done, and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. - -One last thing to mention: often when folding over a `TypeFoldable`, we don’t want to change most -things. We only want to do something when we reach a type. That means there may be a lot of +Notice that here, +we implement `super_fold_with` to go over the fields of `MyFoldable` and call `fold_with` on *them*. +That is, a folder may replace `def_id` and `ty`, but not the whole `MyFoldable` struct. + +Here is another example to put things together: suppose we have a type like `Vec>`. +The `ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. +If we want to do `subst(X => u32)`, +then we would first look at the overall type. +We would see that there are no substitutions to be made at the outer level, +so we would descend one level and look at `Adt(Vec, &[Param(X)])`. +There are still no substitutions to be made here, so we would descend again. +Now we are looking at `Param(X)`, which can be substituted, so we replace it with `u32`. +We can’t descend any more, so we are done, +and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. + +One last thing to mention: often when folding over a `TypeFoldable`, +we don’t want to change most things. +We only want to do something when we reach a type. +That means there may be a lot of `TypeFoldable` types whose implementations basically just forward to their fields’ `TypeFoldable` -implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. -For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is -defined [here]. +implementations. +Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. +For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. +It is defined [here]. **`subst`** In the case of substitutions the [actual folder] is going to be doing the indexing we’ve already mentioned. From 96ca72aba1d8119edf4b53907b57be16dc34ca25 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:18:23 +0200 Subject: [PATCH 04/12] improve ty-fold.md --- src/ty-fold.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ty-fold.md b/src/ty-fold.md index 66dfc648e9..81761252bc 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -11,7 +11,7 @@ The answer is a couple of traits: [`TypeFoldable`] and [`TypeFolder`]. - `TypeFoldable` is implemented by types that embed type information. - It allows you to recursively process the contents of the `TypeFoldable` and do stuff to them. + It allows you to recursively process the contents of `TypeFoldable` and do stuff to them. - `TypeFolder` defines what you want to do with the types you encounter while processing the `TypeFoldable`. @@ -75,7 +75,7 @@ impl TypeFoldable for MyFoldable { Notice that here, we implement `super_fold_with` to go over the fields of `MyFoldable` and call `fold_with` on *them*. -That is, a folder may replace `def_id` and `ty`, but not the whole `MyFoldable` struct. +That is, a folder may replace `def_id` and `ty`, but not the whole `MyFoldable` struct. Here is another example to put things together: suppose we have a type like `Vec>`. The `ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. @@ -86,7 +86,7 @@ so we would descend one level and look at `Adt(Vec, &[Param(X)])`. There are still no substitutions to be made here, so we would descend again. Now we are looking at `Param(X)`, which can be substituted, so we replace it with `u32`. We can’t descend any more, so we are done, -and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. +and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. One last thing to mention: often when folding over a `TypeFoldable`, we don’t want to change most things. From 44938addeefa77dba8cf74ad221a31dc874d17c7 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:18:46 +0200 Subject: [PATCH 05/12] sembr src/building/suggested.md --- src/building/suggested.md | 144 +++++++++++++++++++------------------- 1 file changed, 72 insertions(+), 72 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 01869dfdc3..a938008718 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -5,14 +5,14 @@ Here are some suggestions to make your life easier. ## Installing a pre-push hook -CI will automatically fail your build if it doesn't pass `tidy`, our internal -tool for ensuring code quality. -If you'd like, you can install a [Git -hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) that will +CI will automatically fail your build if it doesn't pass `tidy`, +our internal tool for ensuring code quality. +If you'd like, +you can install a [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) that will automatically run `./x test tidy` on each push, to ensure your code is up to par. If the hook fails then run `./x test tidy --bless` and commit the changes. -If you decide later that the pre-push behavior is undesirable, you can delete -the `pre-push` file in `.git/hooks`. +If you decide later that the pre-push behavior is undesirable, +you can delete the `pre-push` file in `.git/hooks`. A prebuilt git hook lives at [`src/etc/pre-push.sh`]. It can be copied into your `.git/hooks` folder as `pre-push` (without the `.sh` extension!). @@ -24,8 +24,8 @@ You can also install the hook as a step of running `./x setup`! When working on different tasks, you might need to switch between different bootstrap configurations. Sometimes you may want to keep an old configuration for future use. But saving raw config values in -random files and manually copying and pasting them can quickly become messy, especially if you have a -long history of different configurations. +random files and manually copying and pasting them can quickly become messy, +especially if you have a long history of different configurations. To simplify managing multiple configurations, you can create config extensions. @@ -65,8 +65,8 @@ Also, parent extensions always override the inner ones. Checking the "library" tree requires a stage1 compiler, which can be a heavy process on some computers. For this reason, bootstrap has a flag called `--skip-std-check-if-no-download-rustc` that skips checking the "library" tree if `rust.download-rustc` isn't available. -If you want to avoid putting a heavy load on your computer -with `rust-analyzer`, you can add the `--skip-std-check-if-no-download-rustc` flag to your `./x check` command in +If you want to avoid putting a heavy load on your computer with `rust-analyzer`, +you can add the `--skip-std-check-if-no-download-rustc` flag to your `./x check` command in the `rust-analyzer` configuration. ### Project-local rust-analyzer setup @@ -75,15 +75,15 @@ the `rust-analyzer` configuration. 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`. -With custom setup, `rust-analyzer` can use `./x check` -to check the sources, and the stage 0 rustfmt to format them. +With custom setup, `rust-analyzer` can use `./x check` to check the sources, +and the stage 0 rustfmt to format them. The default `rust-analyzer.check.overrideCommand` command line will check all the crates and tools in the repository. If you are working on a specific part, you can override the command to only check the part you are working on to save checking time. -For example, if you are working on the compiler, you can override -the command to `x check compiler --json-output` to only check the compiler part. +For example, if you are working on the compiler, +you can override the command to `x check compiler --json-output` to only check the compiler part. You can run `x check --help --verbose` to see the available parts. Running `./x setup editor` will prompt you to create a project-local LSP config @@ -97,12 +97,12 @@ it will use a separate build directory from manual command-line builds. You can override this your generated LSP config file if you want to save disk space. However, this is not recommended: -- Each build will lock the build directory and force the other to wait, so it - becomes impossible to run command-line builds while rust-analyzer is running +- Each build will lock the build directory and force the other to wait, + so it becomes impossible to run command-line builds while rust-analyzer is running commands in the background. - There is an increased risk of one of the builds deleting previously-built - artifacts due to conflicting compiler flags or other settings, forcing - additional rebuilds in some cases. + artifacts due to conflicting compiler flags or other settings, + forcing additional rebuilds in some cases. ### Visual Studio Code @@ -153,13 +153,13 @@ Steps for this can be [found here][r-a nvim lsp]. 2. Run `./x setup editor`, and select `vscode` to create a `.vscode/settings.json` file. `neoconf` is able to read and update rust-analyzer settings automatically when the project is opened when this file is detected. - Neovim does not expand VS Code's `${workspaceFolder}` variable, so replace each occurrence - in the generated file with the absolute path to your rust repository. + Neovim does not expand VS Code's `${workspaceFolder}` variable, + so replace each occurrence in the generated file with the absolute path to your rust repository. #### coc.nvim -If you're using `coc.nvim`, you can run `./x setup editor` and select `vim` to -create a `.vim/coc-settings.json`. +If you're using `coc.nvim`, +you can run `./x setup editor` and select `vim` to create a `.vim/coc-settings.json`. The settings can be edited with `:CocLocalConfig`. The recommended settings live at [`src/etc/rust_analyzer_settings.json`]. @@ -230,8 +230,8 @@ through [Eglot](https://www.gnu.org/software/emacs/manual/html_node/eglot/). Steps for setting up Eglot with rust-analyzer can be [found here](https://rust-analyzer.github.io/manual.html#eglot). Having set up Emacs & Eglot for Rust development in general, you can run -`./x setup editor` and select `emacs`, which will prompt you to create -`.dir-locals.el` with the recommended configuration for Eglot. +`./x setup editor` and select `emacs`, +which will prompt you to create `.dir-locals.el` with the recommended configuration for Eglot. The recommended settings live at [`src/etc/rust_analyzer_eglot.el`]. For more information on project-specific Eglot configuration, consult [the manual](https://www.gnu.org/software/emacs/manual/html_node/eglot/Project_002dspecific-configuration.html). @@ -239,17 +239,17 @@ manual](https://www.gnu.org/software/emacs/manual/html_node/eglot/Project_002dsp ### Helix Helix comes with built-in LSP and rust-analyzer support. -It can be configured through `languages.toml`, as described -[here](https://docs.helix-editor.com/languages.html). -You can run `./x setup editor` and select `helix`, which will prompt you to -create `languages.toml` with the recommended configuration for Helix. +It can be configured through `languages.toml`, +as described [here](https://docs.helix-editor.com/languages.html). +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). +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`]. @@ -257,8 +257,8 @@ The recommended `rust-analyzer` settings live at [`src/etc/rust_analyzer_zed.jso ## Check, check, and check again When doing simple refactoring, it can be useful to run `./x check` continuously. -If you set up `rust-analyzer` as described above, this will be -done for you every time you save a file. +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). @@ -268,8 +268,8 @@ In fact, it is sometimes useful to put off tests even when you are not 100% sure You can then keep building up refactoring commits and only run the tests at some later time. You can then use `git bisect` to track down **precisely** which commit caused the problem. A nice side-effect of this style -is that you are left with a fairly fine-grained set of commits at the end, all -of which build and pass tests. +is that you are left with a fairly fine-grained set of commits at the end, +all of which build and pass tests. This often helps reviewing. ## Configuring `rustup` to use nightly @@ -284,16 +284,16 @@ rustup override set nightly ``` Don't forget to do this for all directories you have [setup a worktree for]. -You may need to use the -pinned nightly version from `src/stage0`, but often the normal `nightly` channel will work. +You may need to use the pinned nightly version from `src/stage0`, +but often the normal `nightly` channel will work. -**Note** see [the section on vscode] for how to configure it with this real -rustfmt `x` uses, and [the section on rustup] for how to setup `rustup` +**Note** see [the section on vscode] for how to configure it with this real rustfmt `x` uses, +and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler **Note** This does _not_ allow you to build `rustc` with cargo directly. -You still have to use `x` to work on the compiler or standard library, this just -lets you use `cargo fmt`. +You still have to use `x` to work on the compiler or standard library, +this just lets you use `cargo fmt`. [install a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust [setup a worktree for]: ./suggested.md#working-on-multiple-branches-at-the-same-time @@ -303,12 +303,12 @@ lets you use `cargo fmt`. ## Faster Builds with CI-rustc If you are not working on the compiler, you often don't need to build the compiler tree. -For example, you can skip building the compiler and only build the `library` tree or the -tools under `src/tools`. -To achieve that, you have to enable this by setting the `download-rustc` -option in your configuration. -This tells bootstrap to use the latest nightly compiler for `stage > 0` -steps, meaning it will have two precompiled compilers: stage0 compiler and `download-rustc` compiler +For example, +you can skip building the compiler and only build the `library` tree or the tools under `src/tools`. +To achieve that, +you have to enable this by setting the `download-rustc` option in your configuration. +This tells bootstrap to use the latest nightly compiler for `stage > 0` steps, +meaning it will have two precompiled compilers: stage0 compiler and `download-rustc` compiler for `stage > 0` steps. This way, it will never need to build the in-tree compiler. As a result, your build time will be significantly reduced by not building the in-tree compiler. @@ -330,15 +330,15 @@ The sequence of commands you want is as follows: As mentioned, the effect of `--keep-stage-std=1` is that we just _assume_ that the old standard library can be re-used. -If you are editing the compiler, this is -often true: you haven't changed the standard library, after all. -But sometimes, it's not true: for example, if you are editing the "metadata" part of -the compiler, which controls how the compiler encodes types and other states -into the `rlib` files, or if you are editing things that wind up in the metadata -(such as the definition of the MIR). - -That is, you might get weird behavior from a compile when using -`--keep-stage-std=1`, for example, strange [ICEs](../appendix/glossary.md#ice) or other panics. +If you are editing the compiler, this is often true: you haven't changed the standard library, +after all. +But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, +which controls how the compiler encodes types and other states +into the `rlib` files, +or if you are editing things that wind up in the metadata (such as the definition of the MIR). + +That is, you might get weird behavior from a compile when using `--keep-stage-std=1`, +for example, strange [ICEs](../appendix/glossary.md#ice) or other panics. In that case, you should simply remove the `--keep-stage-std=1` from the command and rebuild. You can also use `--keep-stage-std=1` when running tests. @@ -363,17 +363,17 @@ incremental = true ``` Note that incremental compilation will use more disk space than usual. -If disk space is a concern for you, you might want to check the size of the `build` -directory from time to time. +If disk space is a concern for you, +you might want to check the size of the `build` directory from time to time. ## Fine-tuning optimizations Setting `optimize = false` makes the compiler too slow for tests. -However, to improve the test cycle, you can disable optimizations selectively only for the -crates you'll have to rebuild +However, to improve the test cycle, +you can disable optimizations selectively only for the crates you'll have to rebuild ([source](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/incremental.20compilation.20question/near/202712165)). -For example, when working on `rustc_mir_build`, the `rustc_mir_build` and -`rustc_driver` crates take the most time to incrementally rebuild. +For example, when working on `rustc_mir_build`, +the `rustc_mir_build` and `rustc_driver` crates take the most time to incrementally rebuild. You could therefore set the following in the root `Cargo.toml`: ```toml @@ -385,11 +385,11 @@ opt-level = 0 ## Working on multiple branches at the same time -Working on multiple branches in parallel can be a little annoying, since -building the compiler on one branch will cause the old build and the incremental +Working on multiple branches in parallel can be a little annoying, +since 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 +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]. @@ -403,8 +403,8 @@ 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 the following command: +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 the following command: ```bash git worktree add ../rust2 @@ -443,9 +443,9 @@ set up correctly. ### Note -Note that when using nix on a not-NixOS distribution, it may be necessary to set -**`build.patch-binaries-for-nix = true` in `bootstrap.toml`**. Bootstrap tries to detect -whether it's running in nix and enable patching automatically, but this +Note that when using nix on a not-NixOS distribution, +it may be necessary to set **`build.patch-binaries-for-nix = true` in `bootstrap.toml`**. +Bootstrap tries to detect whether it's running in nix and enable patching automatically, but this detection can have false negatives. You can also use your nix shell to manage `bootstrap.toml`: @@ -464,8 +464,8 @@ pkgs.mkShell { ## Shell Completions -If you use Bash, Zsh, Fish or PowerShell, you can find automatically-generated shell -completion scripts for `./x` in +If you use Bash, Zsh, Fish or PowerShell, +you can find automatically-generated shell completion scripts for `./x` in [`src/etc/completions`](https://github.com/rust-lang/rust/tree/HEAD/src/etc/completions). You can use `source ./src/etc/completions/x.` to load completions From 3d71e83e59afd6afd9d94bd37401e16e7f17435b Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:30:02 +0200 Subject: [PATCH 06/12] add option for aggressive reflow --- ci/sembr/src/main.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ci/sembr/src/main.rs b/ci/sembr/src/main.rs index 2d7fd26023..359deab6f6 100644 --- a/ci/sembr/src/main.rs +++ b/ci/sembr/src/main.rs @@ -14,6 +14,9 @@ struct Cli { /// Modify files that do not comply #[arg(long)] overwrite: bool, + /// This reflows file even when it complies (with one sentence per line) + #[arg(long)] + reflow_harder: bool, /// Applies to lines that are to be split #[arg(long, default_value_t = 100)] line_length_limit: usize, @@ -45,7 +48,10 @@ fn main() -> Result<()> { continue; } let old = fs::read_to_string(&path)?; - let new = comply(&old); + let mut new = comply(&old); + if cli.reflow_harder { + new = lengthen_lines(&new, cli.line_length_limit) + } if new == old { compliant.push(path.clone()); } else if cli.overwrite { From a1c18bbd8859a7317edcf14300c274218f921ade Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:30:55 +0200 Subject: [PATCH 07/12] reflow src/building/suggested.md --- src/building/suggested.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index a938008718..ca8dd74ee4 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -229,8 +229,8 @@ Emacs provides support for rust-analyzer with project-local configuration through [Eglot](https://www.gnu.org/software/emacs/manual/html_node/eglot/). Steps for setting up Eglot with rust-analyzer can be [found here](https://rust-analyzer.github.io/manual.html#eglot). -Having set up Emacs & Eglot for Rust development in general, you can run -`./x setup editor` and select `emacs`, +Having set up Emacs & Eglot for Rust development in general, +you can run `./x setup editor` and select `emacs`, which will prompt you to create `.dir-locals.el` with the recommended configuration for Eglot. The recommended settings live at [`src/etc/rust_analyzer_eglot.el`]. For more information on project-specific Eglot configuration, consult [the @@ -288,8 +288,7 @@ You may need to use the pinned nightly version from `src/stage0`, but often the normal `nightly` channel will work. **Note** see [the section on vscode] for how to configure it with this real rustfmt `x` uses, -and [the section on rustup] for how to setup `rustup` -toolchain for your bootstrapped compiler +and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler **Note** This does _not_ allow you to build `rustc` with cargo directly. You still have to use `x` to work on the compiler or standard library, @@ -333,8 +332,7 @@ old standard library can be re-used. If you are editing the compiler, this is often true: you haven't changed the standard library, after all. But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, -which controls how the compiler encodes types and other states -into the `rlib` files, +which controls how the compiler encodes types and other states into the `rlib` files, or if you are editing things that wind up in the metadata (such as the definition of the MIR). That is, you might get weird behavior from a compile when using `--keep-stage-std=1`, @@ -389,8 +387,8 @@ Working on multiple branches in parallel can be a little annoying, since 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. +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. @@ -445,8 +443,8 @@ set up correctly. Note that when using nix on a not-NixOS distribution, it may be necessary to set **`build.patch-binaries-for-nix = true` in `bootstrap.toml`**. -Bootstrap tries to detect whether it's running in nix and enable patching automatically, but this -detection can have false negatives. +Bootstrap tries to detect whether it's running in nix and enable patching automatically, +but this detection can have false negatives. You can also use your nix shell to manage `bootstrap.toml`: From 68dd6190c67c0c4e685d43c1f7f00812d96aaa80 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:32:42 +0200 Subject: [PATCH 08/12] reflow src/ty-fold.md --- src/ty-fold.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/ty-fold.md b/src/ty-fold.md index 81761252bc..f7fce9a981 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -7,8 +7,7 @@ to find any usages of the bound vars in order to replace them. Binders can wrap an arbitrary Rust type `T`, not just a `Ty`. So, how do we implement the `instantiate` methods on the `Early/Binder` types? -The answer is a couple of traits: [`TypeFoldable`] -and [`TypeFolder`]. +The answer is a couple of traits: [`TypeFoldable`] and [`TypeFolder`]. - `TypeFoldable` is implemented by types that embed type information. It allows you to recursively process the contents of `TypeFoldable` and do stuff to them. From ac029feec6296e662d718821a517ff015d3f05b7 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:33:14 +0200 Subject: [PATCH 09/12] sembr src/tests/intro.md --- src/tests/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index f8cd390a55..8c1e6c65b1 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -16,8 +16,8 @@ The main test harness for testing the compiler itself is a tool called [compilet [compiletest] supports running different styles of tests, organized into *test suites*. -A *test mode* may provide common presets/behavior for a set of *test -suites*. [compiletest]-supported tests are located in the [`tests`] directory. +A *test mode* may provide common presets/behavior for a set of *test suites*. +[compiletest]-supported tests are located in the [`tests`] directory. The [Compiletest chapter][compiletest] goes into detail on how to use this tool. From 1bcff9ce762d02bd6c1a12aa7c20acdc2ce03de7 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 17:45:28 +0200 Subject: [PATCH 10/12] reflow src/tests/ecosystem-test-jobs/fuchsia.md --- src/tests/ecosystem-test-jobs/fuchsia.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/tests/ecosystem-test-jobs/fuchsia.md b/src/tests/ecosystem-test-jobs/fuchsia.md index ca7a9f482f..19e3fb44bb 100644 --- a/src/tests/ecosystem-test-jobs/fuchsia.md +++ b/src/tests/ecosystem-test-jobs/fuchsia.md @@ -53,8 +53,7 @@ After running a Docker build, you'll find the Fuchsia checkout inside the `obj/test-x86_64-fuchsia/fuchsia` directory of your Rust checkout. If you modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to `KEEP_CHECKOUT=1`, -you can change the checkout as needed and rerun -the build command above. +you can change the checkout as needed and rerun the build command above. This will reuse all the build results from before. You can find more options to customize the Fuchsia checkout in the [build-fuchsia.sh] script. From 93f0e54aced2f8f02848205533a2d5521fd546e1 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 18:00:23 +0200 Subject: [PATCH 11/12] sembr src/building/bootstrapping/what-bootstrapping-does.md --- .../bootstrapping/what-bootstrapping-does.md | 132 +++++++++--------- 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/src/building/bootstrapping/what-bootstrapping-does.md b/src/building/bootstrapping/what-bootstrapping-does.md index b986895c3b..15ad385c17 100644 --- a/src/building/bootstrapping/what-bootstrapping-does.md +++ b/src/building/bootstrapping/what-bootstrapping-does.md @@ -16,12 +16,12 @@ See [bootstrap/README.md][bootstrap-internals] to read about bootstrap internals Compiling `rustc` is done in stages. Here's a diagram, adapted from Jynn -Nelson's [talk on bootstrapping][rustconf22-talk] at RustConf 2022, with -detailed explanations below. +Nelson's [talk on bootstrapping][rustconf22-talk] at RustConf 2022, +with detailed explanations below. The `A`, `B`, `C`, and `D` show the ordering of the stages of bootstrapping. -Blue nodes are -downloaded, yellow +Blue nodes are downloaded, +yellow nodes are built with the `stage0` compiler, and green nodes are built with the `stage1` compiler. @@ -54,8 +54,8 @@ The precompiled stage0 compiler is then used only to compile [`src/bootstrap`] a with precompiled stage0 std. Note that to build the stage1 compiler we use the precompiled stage0 compiler and std. -Therefore, to use a compiler with a std that is freshly built from the tree, you need to -build the stage2 compiler. +Therefore, to use a compiler with a std that is freshly built from the tree, +you need to build the stage2 compiler. There are two concepts at play here: a compiler (with its set of dependencies) and its 'target' or 'object' libraries (`std` and `rustc`). @@ -77,8 +77,8 @@ The `stage1` compiler itself was built by precompiled `stage0` compiler and std and hence not by the source in your working directory. This means that the ABI generated by the `stage0` compiler may not match the ABI that would have been made -by the `stage1` compiler, which can cause problems for dynamic libraries, tests -and tools using `rustc_private`. +by the `stage1` compiler, which can cause problems for dynamic libraries, +tests and tools using `rustc_private`. Note that the `proc_macro` crate avoids this issue with a `C` FFI layer called `proc_macro::bridge`, allowing it to be used with `stage1`. @@ -119,20 +119,20 @@ For more information about stages, [see below](#understanding-stages-of-bootstra ## Complications of bootstrapping -Since the build system uses the current beta compiler to build a `stage1` -bootstrapping compiler, the compiler source code can't use some features until +Since the build system uses the current beta compiler to build a `stage1` bootstrapping compiler, +the compiler source code can't use some features until they reach beta (because otherwise the beta compiler doesn't support them). -On the other hand, for [compiler intrinsics][intrinsics] and internal features, the -features _have_ to be used. +On the other hand, for [compiler intrinsics][intrinsics] and internal features, +the features _have_ to be used. Additionally, the compiler makes heavy use of `nightly` features (`#![feature(...)]`). How can we resolve this problem? There are two methods used: -1. The build system sets `--cfg bootstrap` when building with `stage0`, so we - can use `cfg(not(bootstrap))` to only use features when built with `stage1`. - Setting `--cfg bootstrap` in this way is used for features that were just - stabilized, which require `#![feature(...)]` when built with `stage0`, but not for `stage1`. +1. The build system sets `--cfg bootstrap` when building with `stage0`, + so we can use `cfg(not(bootstrap))` to only use features when built with `stage1`. + Setting `--cfg bootstrap` in this way is used for features that were just stabilized, + which require `#![feature(...)]` when built with `stage0`, but not for `stage1`. 2. The build system sets `RUSTC_BOOTSTRAP=1`. This special variable means to _break the stability guarantees_ of Rust: allowing use of `#![feature(...)]` @@ -152,8 +152,8 @@ The convention `./x` uses is that: - A `--stage N` flag means to run the stage N compiler (`stageN/rustc`). - A "stage N artifact" is a build artifact that is _produced_ by the stage N compiler. -- The stage N+1 compiler is assembled from stage N *artifacts*. This process is - called _uplifting_. +- The stage N+1 compiler is assembled from stage N *artifacts*. + This process is called _uplifting_. #### Build artifacts @@ -186,10 +186,10 @@ Build artifacts include, but are not limited to: - `./x test --stage 0 compiler/rustc` builds the compiler but runs no tests: it's running `cargo test -p rustc`, but `cargo` doesn't understand Rust's tests. You shouldn't need to use this; use `test` instead (without arguments). -- `./x build --stage 0 compiler/rustc` builds the compiler, but does not build - `libstd` or even `libcore`. - Most of the time, you'll want `./x build library` - instead, which allows compiling programs without needing to define lang items. +- `./x build --stage 0 compiler/rustc` builds the compiler, + but does not build `libstd` or even `libcore`. + Most of the time, you'll want `./x build library` instead, + which allows compiling programs without needing to define lang items. ### Building vs. running @@ -199,8 +199,8 @@ will later be uplifted to be the stage1 compiler_. In each stage besides 0, two major steps are performed: 1. `std` is compiled by the stage N compiler. -2. That `std` is linked to programs built by the stage N compiler, including the - stage N artifacts (stage N+1 compiler). +2. That `std` is linked to programs built by the stage N compiler, + including the stage N artifacts (stage N+1 compiler). This is somewhat intuitive if one thinks of the stage N artifacts as "just" another program we are building with the stage N compiler: `build --stage N @@ -211,23 +211,23 @@ compiler/rustc` is linking the stage N artifacts to the `std` built by the stage Note that there are two `std` libraries in play here: 1. The library _linked_ to `stageN/rustc`, which was built by stage N-1 (stage N-1 `std`) -2. The library _used to compile programs_ with `stageN/rustc`, which was built - by stage N (stage N `std`). +2. The library _used to compile programs_ with `stageN/rustc`, + which was built by stage N (stage N `std`). Stage N `std` is pretty much necessary for any useful work with the stage N compiler. Without it, you can only compile programs with `#![no_core]` -- not terribly useful! The reason these need to be different is because they aren't necessarily -ABI-compatible: there could be new layout optimizations, changes to `MIR`, or -other changes to Rust metadata on `nightly` that aren't present in beta. +ABI-compatible: there could be new layout optimizations, changes to `MIR`, +or other changes to Rust metadata on `nightly` that aren't present in beta. This is also where `--keep-stage 1 library/std` comes into play. Since most changes to the compiler don't actually change the ABI, once you've produced a `std` in `stage1`, you can probably just reuse it with a different compiler. If the ABI hasn't changed, you're good to go; no need to spend time recompiling that `std`. The flag `--keep-stage` simply instructs the build script to assume -the previous compile is fine and copies those artifacts into the appropriate -place, skipping the `cargo` invocation. +the previous compile is fine and copies those artifacts into the appropriate place, +skipping the `cargo` invocation. ### Cross-compiling rustc @@ -235,8 +235,8 @@ place, skipping the `cargo` invocation. For instance, you might want to build an ARM version of rustc using an x86 machine. Building `stage2` `std` is different when you are cross-compiling. -This is because `./x` uses the following logic: if `HOST` and `TARGET` are the -same, it will reuse `stage1` `std` for `stage2`! +This is because `./x` uses the following logic: if `HOST` and `TARGET` are the same, +it will reuse `stage1` `std` for `stage2`! This is sound because `stage1` `std` was compiled with the `stage1` compiler, i.e. a compiler using the source code you currently have checked out. @@ -250,23 +250,23 @@ So, the `stage2` compiler has to recompile `std` for the target. ### What is a 'sysroot'? -When you build a project with `cargo`, the build artifacts for dependencies are -normally stored in `target/debug/deps`. -This only contains dependencies `cargo` -knows about; in particular, it doesn't have the standard library. +When you build a project with `cargo`, +the build artifacts for dependencies are normally stored in `target/debug/deps`. +This only contains dependencies `cargo` knows about; in particular, +it doesn't have the standard library. Where do `std` or `proc_macro` come from? -They come from the **sysroot**, the root of a number -of directories where the compiler loads build artifacts at runtime. -The `sysroot` doesn't just store the standard library, though - it includes anything -that needs to be loaded at runtime. +They come from the **sysroot**, +the root of a number of directories where the compiler loads build artifacts at runtime. +The `sysroot` doesn't just store the standard library, +though - it includes anything that needs to be loaded at runtime. That includes (but is not limited to): - Libraries `libstd`/`libtest`/`libproc_macro`. - Compiler crates themselves, when using `rustc_private`. In-tree, these are always present; out-of-tree, you need to install `rustc-dev` with `rustup`. - Shared object file `libLLVM.so` for the LLVM project. - In-tree, this is either built from source or downloaded from CI; out-of-tree, you need to install - `llvm-tools-preview` with `rustup`. + In-tree, this is either built from source or downloaded from CI; out-of-tree, + you need to install `llvm-tools-preview` with `rustup`. All the artifacts listed so far are *compiler* runtime dependencies. You can see them with `rustc --print sysroot`: @@ -293,16 +293,16 @@ libcompiler_builtins-ef2408da76957905.rlib Directory `lib/rustlib/` includes libraries like `hashbrown` and `cfg_if`, which are not part of the public API of the standard library, but are used to implement it. -Also,`lib/rustlib/` is part of the search path for linkers, but -`lib` will never be part of the search path. +Also,`lib/rustlib/` is part of the search path for linkers, +but `lib` will never be part of the search path. #### `-Z force-unstable-if-unmarked` Since `lib/rustlib/` is part of the search path we have to be careful about which crates are included in it. In particular, all crates except for the -standard library are built with the flag `-Z force-unstable-if-unmarked`, which -means that you have to use `#![feature(rustc_private)]` in order to load it (as +standard library are built with the flag `-Z force-unstable-if-unmarked`, +which means that you have to use `#![feature(rustc_private)]` in order to load it (as opposed to the standard library, which is always available). The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help @@ -323,12 +323,12 @@ This flag has the following effects: - Marks the crate as "`unstable`" with the `rustc_private` feature if it is not itself marked as `stable` or `unstable`. - Allows these crates to access other forced-unstable crates without any need for attributes. - Normally, a crate would need a `#![feature(rustc_private)]` - attribute to use other `unstable` crates. - However, that would make it - impossible for a crate from crates.io to access its own dependencies since - that crate won't have a `feature(rustc_private)` attribute, but *everything* - is compiled with `-Z force-unstable-if-unmarked`. + Normally, + a crate would need a `#![feature(rustc_private)]` attribute to use other `unstable` crates. + However, + that would make it impossible for a crate from crates.io to access its own dependencies since + that crate won't have a `feature(rustc_private)` attribute, + but *everything* is compiled with `-Z force-unstable-if-unmarked`. Code which does not use `-Z force-unstable-if-unmarked` should include the `#![feature(rustc_private)]` crate attribute to access these forced-unstable crates. @@ -348,10 +348,10 @@ You can find more discussion about sysroots in: Conveniently `./x` allows you to pass stage-specific flags to `rustc` and `cargo` when bootstrapping. The `RUSTFLAGS_BOOTSTRAP` environment variable is -passed as `RUSTFLAGS` to the bootstrap stage (`stage0`), and -`RUSTFLAGS_NOT_BOOTSTRAP` is passed when building artifacts for later stages. -`RUSTFLAGS` will work, but also affects the build of `bootstrap` itself, so it -will be rare to want to use it. +passed as `RUSTFLAGS` to the bootstrap stage (`stage0`), +and `RUSTFLAGS_NOT_BOOTSTRAP` is passed when building artifacts for later stages. +`RUSTFLAGS` will work, but also affects the build of `bootstrap` itself, +so it will be rare to want to use it. Finally, `MAGIC_EXTRA_RUSTFLAGS` bypasses the `cargo` cache to pass flags to rustc without recompiling all dependencies. @@ -370,19 +370,19 @@ which you can use to find out the options accepted by the runner. ## Environment Variables During bootstrapping, there are a bunch of compiler-internal environment variables that are used. -If you are trying to run an intermediate version of -`rustc`, sometimes you may need to set some of these environment variables manually. +If you are trying to run an intermediate version of `rustc`, +sometimes you may need to set some of these environment variables manually. Otherwise, you get an error like the following: ```text thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/src/result.rs:1165:5 ``` -If `./stageN/bin/rustc` gives an error about environment variables, that usually -means something is quite wrong -- such as you're trying to compile `rustc` or +If `./stageN/bin/rustc` gives an error about environment variables, +that usually means something is quite wrong -- such as you're trying to compile `rustc` or `std` or something which depends on environment variables. -In the unlikely case that you actually need to invoke `rustc` in such a situation, you can tell the -bootstrap shim to print all `env` variables by adding `-vvv` to your `x` command. +In the unlikely case that you actually need to invoke `rustc` in such a situation, +you can tell the bootstrap shim to print all `env` variables by adding `-vvv` to your `x` command. Finally, bootstrap makes use of the [cc-rs crate] which has [its own method][env-vars] of configuring `C` compilers and `C` flags via environment variables. @@ -392,8 +392,8 @@ method][env-vars] of configuring `C` compilers and `C` flags via environment var ## Clarification of build command's `stdout` -In this part, we will investigate the build command's `stdout` in an action -(similar, but more detailed and complete documentation compare to topic above). +In this part, we will investigate the build command's `stdout` in an action (similar, +but more detailed and complete documentation compare to topic above). When you execute `x build --dry-run` command, the build output will be something like the following: ```text @@ -410,8 +410,8 @@ Building rustdoc for stage1 (x86_64-unknown-linux-gnu) ### Building stage0 {std,compiler} artifacts -These steps use the provided (downloaded, usually) compiler to compile the local -Rust source into libraries we can use. +These steps use the provided (downloaded, +usually) compiler to compile the local Rust source into libraries we can use. ### Copying stage0 \{std,rustc\} From 35ded2f65b3a082d79f6eb85b0bb52724340dee2 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Mon, 21 Sep 2026 18:10:37 +0200 Subject: [PATCH 12/12] improve building/bootstrapping/what-bootstrapping-does.md --- .../bootstrapping/what-bootstrapping-does.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/building/bootstrapping/what-bootstrapping-does.md b/src/building/bootstrapping/what-bootstrapping-does.md index 15ad385c17..4572d001f1 100644 --- a/src/building/bootstrapping/what-bootstrapping-does.md +++ b/src/building/bootstrapping/what-bootstrapping-does.md @@ -78,7 +78,7 @@ and hence not by the source in your working directory. This means that the ABI generated by the `stage0` compiler may not match the ABI that would have been made by the `stage1` compiler, which can cause problems for dynamic libraries, -tests and tools using `rustc_private`. +tests, and tools using `rustc_private`. Note that the `proc_macro` crate avoids this issue with a `C` FFI layer called `proc_macro::bridge`, allowing it to be used with `stage1`. @@ -122,7 +122,7 @@ For more information about stages, [see below](#understanding-stages-of-bootstra Since the build system uses the current beta compiler to build a `stage1` bootstrapping compiler, the compiler source code can't use some features until they reach beta (because otherwise the beta compiler doesn't support them). -On the other hand, for [compiler intrinsics][intrinsics] and internal features, +On the other hand, for [compiler intrinsics] and internal features, the features _have_ to be used. Additionally, the compiler makes heavy use of `nightly` features (`#![feature(...)]`). How can we resolve this problem? @@ -140,7 +140,7 @@ There are two methods used: _Setting `RUSTC_BOOTSTRAP=1` should never be used except when bootstrapping the compiler._ [boot]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) -[intrinsics]: ../../appendix/glossary.md#intrinsic +[compiler intrinsics]: ../../appendix/glossary.md#intrinsic ## Understanding stages of bootstrap @@ -257,8 +257,8 @@ it doesn't have the standard library. Where do `std` or `proc_macro` come from? They come from the **sysroot**, the root of a number of directories where the compiler loads build artifacts at runtime. -The `sysroot` doesn't just store the standard library, -though - it includes anything that needs to be loaded at runtime. +The `sysroot` doesn't just store the standard library though; +it includes anything that needs to be loaded at runtime. That includes (but is not limited to): - Libraries `libstd`/`libtest`/`libproc_macro`. @@ -393,7 +393,7 @@ method][env-vars] of configuring `C` compilers and `C` flags via environment var ## Clarification of build command's `stdout` In this part, we will investigate the build command's `stdout` in an action (similar, -but more detailed and complete documentation compare to topic above). +but more detailed and complete documentation compared to topic above). When you execute `x build --dry-run` command, the build output will be something like the following: ```text