rustc-dev-guide subtree update #151029

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

rust-bors merged 31 commits into rust-lang:main from tshepang:rdg-sync

Jan 13, 2026

src/doc/rustc-dev-guide/ci/sembr/src/main.rs

-Original file line number
+Diff line change
@@ Expand Up / @@ -27,7 +27,7 @@ static REGEX_SPLIT: LazyLock<Regex> = @@
         LazyLock::new(|| Regex::new(r"([^\.\d\-\*]\.|[^r]\?|!)\s").unwrap());
     // list elements, numbered (1.) or not  (- and *)
     static REGEX_LIST_ENTRY: LazyLock<Regex> =
-        LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*)\s+").unwrap());
+        LazyLock::new(|| Regex::new(r"^\s*(\d\.|\-|\*|\d\))\s+").unwrap());
     fn main() -> Result<()> {
         let cli = Cli::parse();
@@ Expand Down Expand Up / @@ -80,6 +80,7 @@ fn ignore(line: &str, in_code_block: bool) -> bool { @@
         in_code_block
             || line.to_lowercase().contains("e.g.")
             || line.to_lowercase().contains("n.b.")
+            || line.contains(" etc.")
             || line.contains("i.e.")
             || line.contains("et. al")
             || line.contains('|')
@@ Expand Down Expand Up / @@ -189,9 +190,11 @@ must! be. split? @@
     ignore | tables
     ignore e.g. and
     ignore i.e. and
+    ignore etc. and
     ignore E.g. too
     - list. entry
      * list. entry
+) list. entry
     ```
     some code. block
     ```
@@ Expand All / @@ -212,11 +215,14 @@ split? @@
     ignore | tables
     ignore e.g. and
     ignore i.e. and
+    ignore etc. and
     ignore E.g. too
     - list.
       entry
      * list.
        entry
+) list.
+         entry
     ```
     some code. block
     ```
@@ Expand Down @@

src/doc/rustc-dev-guide/rust-version

Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		85c8ff69cb3efd950395cc444a54bbbdad668865
		44a5b55557c26353f388400d7da95527256fe260

src/doc/rustc-dev-guide/src/ambig-unambig-ty-and-consts.md

-Original file line number
+Diff line change
@@ Expand Up / @@ -6,7 +6,7 @@ parse. @@
     ```rust
     fn func<T, const N: usize>(arg: T) {
-        //                           ^ Unambig type position
+        //                          ^ Unambig type position
         let a: _ = arg;
         //     ^ Unambig type position
@@ Expand Down Expand Up / @@ -108,4 +108,4 @@ This has a number of benefits: @@
     [`ast::AnonConst`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.AnonConst.html
     [`hir::GenericArg::Infer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Infer
     [`ast::ExprKind::Underscore`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Underscore
-    [`ast::Ty::Path(N)`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Path
+    [`ast::Ty::Path(N)`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Path

src/doc/rustc-dev-guide/src/building/new-target.md

            
                      Original file line number
                      Diff line number
                      Diff line change
                  
    @@ -1,7 +1,7 @@
  
    # Adding a new target

    These are a set of steps to add support for a new target. There are

    numerous end states and paths to get there, so not all sections may be

    These are a set of steps to add support for a new target.

    There are numerous end states and paths to get there, so not all sections may be

    relevant to your desired goal.

    See also the associated documentation in the [target tier policy].

    @@ -11,8 +11,8 @@ See also the associated documentation in the [target tier policy].
  
    ## Specifying a new LLVM

    For very new targets, you may need to use a different fork of LLVM

    than what is currently shipped with Rust. In that case, navigate to

    the `src/llvm-project` git submodule (you might need to run `./x

    than what is currently shipped with Rust.

    In that case, navigate to the `src/llvm-project` git submodule (you might need to run `./x

    check` at least once so the submodule is updated), check out the

    appropriate commit for your fork, then commit that new submodule

    reference in the main Rust repository.

    @@ -31,11 +31,9 @@ git commit -m 'Use my custom LLVM'
  
    ### Using pre-built LLVM

    If you have a local LLVM checkout that is already built, you may be

    able to configure Rust to treat your build as the system LLVM to avoid

    redundant builds.

    able to configure Rust to treat your build as the system LLVM to avoid redundant builds.

    You can tell Rust to use a pre-built version of LLVM using the `target` section

    of `bootstrap.toml`:

    You can tell Rust to use a pre-built version of LLVM using the `target` section of `bootstrap.toml`:

    ```toml

    [target.x86_64-unknown-linux-gnu]

    @@ -48,8 +46,8 @@ before, though they may be different from your system:
  
    - `/usr/bin/llvm-config-8`

    - `/usr/lib/llvm-8/bin/llvm-config`

    Note that you need to have the LLVM `FileCheck` tool installed, which is used

    for codegen tests. This tool is normally built with LLVM, but if you use your

    Note that you need to have the LLVM `FileCheck` tool installed, which is used for codegen tests.

    This tool is normally built with LLVM, but if you use your

    own preinstalled LLVM, you will need to provide `FileCheck` in some other way.

    On Debian-based systems, you can install the `llvm-N-tools` package (where `N`

    is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify

    @@ -58,8 +56,8 @@ or you can disable codegen test with the `codegen-tests` item in `bootstrap.toml
  
    ## Creating a target specification

    You should start with a target JSON file. You can see the specification

    for an existing target using `--print target-spec-json`:

    You should start with a target JSON file.

    You can see the specification for an existing target using `--print target-spec-json`:

    ```

    rustc -Z unstable-options --target=wasm32-unknown-unknown --print target-spec-json

    @@ -70,42 +68,22 @@ Save that JSON to a file and modify it as appropriate for your target.
  
    ### Adding a target specification

    Once you have filled out a JSON specification and been able to compile

    somewhat successfully, you can copy the specification into the

    compiler itself.

    somewhat successfully, you can copy the specification into the compiler itself.

    You will need to add a line to the big table inside of the

    `supported_targets` macro in the `rustc_target::spec` module. You

    will then add a corresponding file for your new target containing a

    `supported_targets` macro in the `rustc_target::spec` module.

    You will then add a corresponding file for your new target containing a

    `target` function.

    Look for existing targets to use as examples.

    After adding your target to the `rustc_target` crate you may want to add

    `core`, `std`, ... with support for your new target. In that case you will

    probably need access to some `target_*` cfg. Unfortunately when building with

    stage0 (a precompiled compiler), you'll get an error that the target cfg is

    unexpected because stage0 doesn't know about the new target specification and

    we pass `--check-cfg` in order to tell it to check.

    To fix the errors you will need to manually add the unexpected value to the

    different `Cargo.toml` in `library/{std,alloc,core}/Cargo.toml`. Here is an

    example for adding `NEW_TARGET_ARCH` as `target_arch`:

    *`library/std/Cargo.toml`*:

    ```diff

      [lints.rust.unexpected_cfgs]

      level = "warn"

      check-cfg = [

          'cfg(bootstrap)',

    -      'cfg(target_arch, values("xtensa"))',

    +      # #[cfg(bootstrap)] NEW_TARGET_ARCH

    +      'cfg(target_arch, values("xtensa", "NEW_TARGET_ARCH"))',

    ```

    To use this target in bootstrap, we need to explicitly add the target triple to the `STAGE0_MISSING_TARGETS`

    list in `src/bootstrap/src/core/sanity.rs`. This is necessary because the default compiler bootstrap uses does

    not recognize the new target we just added. Therefore, it should be added to `STAGE0_MISSING_TARGETS` so that the

    bootstrap is aware that this target is not yet supported by the stage0 compiler.

    To use this target in bootstrap, we need to explicitly add the target triple to

    the `STAGE0_MISSING_TARGETS` list in `src/bootstrap/src/core/sanity.rs`.

    This is necessary because the default bootstrap compiler (typically a beta compiler)

    does not recognize the new target we just added.

    Therefore, it should be added to

    `STAGE0_MISSING_TARGETS` so that the bootstrap is aware that this target is not

    yet supported by the stage0 compiler.

    ```diff

    const STAGE0_MISSING_TARGETS: &[&str] = &[

    @@ -116,9 +94,9 @@ const STAGE0_MISSING_TARGETS: &[&str] = &[
  
    ## Patching crates

    You may need to make changes to crates that the compiler depends on,

    such as [`libc`][] or [`cc`][]. If so, you can use Cargo's

    [`[patch]`][patch] ability. For example, if you want to use an

    unreleased version of `libc`, you can add it to the top-level

    such as [`libc`][] or [`cc`][].

    If so, you can use Cargo's [`[patch]`][patch] ability.

    For example, if you want to use an unreleased version of `libc`, you can add it to the top-level

    `Cargo.toml` file:

    ```diff

    @@ -138,9 +116,9 @@ index 1e83f05e0ca..4d0172071c1 100644
  
    After this, run `cargo update -p libc` to update the lockfiles.

    Beware that if you patch to a local `path` dependency, this will enable

    warnings for that dependency. Some dependencies are not warning-free, and due

    to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start

    to fail.

    warnings for that dependency.

    Some dependencies are not warning-free, and due

    to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start to fail.

    To work around warnings, you may want to:

    - Modify the dependency to remove the warnings

    - Or for local development purposes, suppress the warnings by setting deny-warnings = false in bootstrap.toml.

    @@ -157,8 +135,7 @@ deny-warnings = false
  
    ## Cross-compiling

    Once you have a target specification in JSON and in the code, you can

    cross-compile `rustc`:

    Once you have a target specification in JSON and in the code, you can cross-compile `rustc`:

    ```

    DESTDIR=/path/to/install/in \

src/doc/rustc-dev-guide/src/const-generics.md

-Original file line number
+Diff line change
@@ Expand Up @@
     This also makes it much more likely that the compiler will ICE or atleast incidentally emit some kind of error if we *do* accidentally allow generic parameters in an anon const, as the anon const will have none of the necessary information in its environment to properly handle the generic parameters.
+    #### Array repeat expressions
+    The one exception to all of the above is repeat counts of array expressions. As a *backwards compatibility hack* we allow the repeat count const argument to use generic parameters.
     ```rust
     fn foo<T: Sized>() {
-        let a = [1_u8;  size_of::<*mut T>()];
+        let a = [1_u8; size_of::<T>()];
     }
     ```
-    The one exception to all of the above is repeat counts of array expressions. As a *backwards compatibility hack* we allow the repeat count const argument to use generic parameters.
     However, to avoid most of the problems involved in allowing generic parameters in anon const const arguments we require that the constant be evaluated before monomorphization (e.g. during type checking). In some sense we only allow generic parameters here when they are semantically unused.
     In the previous example the anon const can be evaluated for any type parameter `T` because raw pointers to sized types always have the same size (e.g. `8` on 64bit platforms).
@@ Expand Down @@

src/doc/rustc-dev-guide/src/external-repos.md

            
                      Original file line number
                      Diff line number
                      Diff line change
                  
    @@ -29,9 +29,9 @@ The following external projects are managed using some form of a `subtree`:
  
    In contrast to `submodule` dependencies

    (see below for those), the `subtree` dependencies are just regular files and directories which can

    be updated in tree. However, if possible, enhancements, bug fixes, etc. specific

    to these tools should be filed against the tools directly in their respective

    upstream repositories. The exception is that when rustc changes are required to

    be updated in-tree. However, if possible, enhancements, bug fixes, etc. specific

    to these tools should be filed against the tools directly in their respective upstream repositories.

    The exception is that when rustc changes are required to

    implement a new tool feature or test, that should happen in one collective rustc PR.

    `subtree` dependencies are currently managed by two distinct approaches:

    @@ -51,7 +51,9 @@ implement a new tool feature or test, that should happen in one collective rustc
  
    ### Josh subtrees

    The [josh] tool is an alternative to git subtrees, which manages git history in a different way and scales better to larger repositories. Specific tooling is required to work with josh. We provide a helper [`rustc-josh-sync`][josh-sync] tool to help with the synchronization, described [below](#synchronizing-a-josh-subtree).

    The [josh] tool is an alternative to git subtrees, which manages git history in a different way and scales better to larger repositories.

    Specific tooling is required to work with josh.

    We provide a helper [`rustc-josh-sync`][josh-sync] tool to help with the synchronization, described [below](#synchronizing-a-josh-subtree).

    ### Synchronizing a Josh subtree

    @@ -69,24 +71,24 @@ changes from the subtree to rust-lang/rust) are performed from the subtree repos
  
    switch to its repository checkout directory in your terminal).

    #### Performing pull

    1) Checkout a new branch that will be used to create a PR into the subtree

    2) Run the pull command

    1. Checkout a new branch that will be used to create a PR into the subtree

    2. Run the pull command

        ```

        rustc-josh-sync pull

        ```

    3) Push the branch to your fork and create a PR into the subtree repository

    3. Push the branch to your fork and create a PR into the subtree repository

        - If you have `gh` CLI installed, `rustc-josh-sync` can create the PR for you.

    #### Performing push

    > NOTE:

    > Before you proceed, look at some guidance related to Git [on josh-sync README].

    1) Run the push command to create a branch named `<branch-name>` in a `rustc` fork under the `<gh-username>` account

    1. Run the push command to create a branch named `<branch-name>` in a `rustc` fork under the `<gh-username>` account

        ```

        rustc-josh-sync push <branch-name> <gh-username>

        ```

    2) Create a PR from `<branch-name>` into `rust-lang/rust`

    2. Create a PR from `<branch-name>` into `rust-lang/rust`

    ### Creating a new Josh subtree dependency

    @@ -97,7 +99,8 @@ If you want to migrate a repository dependency from `git subtree` or `git submod
  
    Periodically the changes made to subtree based dependencies need to be synchronized between this

    repository and the upstream tool repositories.

    Subtree synchronizations are typically handled by the respective tool maintainers. Other users

    Subtree synchronizations are typically handled by the respective tool maintainers.

    Other users

    are welcome to submit synchronization PRs, however, in order to do so you will need to modify

    your local git installation and follow a very precise set of instructions.

    These instructions are documented, along with several useful tips and tricks, in the

    @@ -108,8 +111,8 @@ use the correct corresponding subtree directory and remote repository.
  
    The synchronization process goes in two directions: `subtree push` and `subtree pull`.

    A `subtree push` takes all the changes that happened to the copy in this repo and creates commits

    on the remote repo that match the local changes. Every local

    commit that touched the subtree causes a commit on the remote repo, but

    on the remote repo that match the local changes.

    Every local commit that touched the subtree causes a commit on the remote repo, but

    is modified to move the files from the specified directory to the tool repo root.

    A `subtree pull` takes all changes since the last `subtree pull`

    @@ -119,14 +122,17 @@ the tool changes into the specified directory in the Rust repository.
  
    It is recommended that you always do a push first and get that merged to the default branch of the tool.

    Then, when you do a pull, the merge works without conflicts.

    While it's definitely possible to resolve conflicts during a pull, you may have to redo the conflict

    resolution if your PR doesn't get merged fast enough and there are new conflicts. Do not try to

    rebase the result of a `git subtree pull`, rebasing merge commits is a bad idea in general.

    resolution if your PR doesn't get merged fast enough and there are new conflicts.

    Do not try to

    rebase the result of a `git subtree pull`; rebasing merge commits is a bad idea in general.

    You always need to specify the `-P` prefix to the subtree directory and the corresponding remote

    repository. If you specify the wrong directory or repository

    repository.

    If you specify the wrong directory or repository

    you'll get very fun merges that try to push the wrong directory to the wrong remote repository.

    Luckily you can just abort this without any consequences by throwing away either the pulled commits

    in rustc or the pushed branch on the remote and try again. It is usually fairly obvious

    in rustc or the pushed branch on the remote and try again.

    It is usually fairly obvious

    that this is happening because you suddenly get thousands of commits that want to be synchronized.

    [clippy-sync-docs]: https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html

    @@ -140,33 +146,34 @@ repository's root directory!)
  
    git subtree add -P src/tools/clippy https://github.com/rust-lang/rust-clippy.git master

    ```

    This will create a new commit, which you may not rebase under any circumstances! Delete the commit

    and redo the operation if you need to rebase.

    This will create a new commit, which you may not rebase under any circumstances!

    Delete the commit and redo the operation if you need to rebase.

    Now you're done, the `src/tools/clippy` directory behaves as if Clippy were

    part of the rustc monorepo, so no one but you (or others that synchronize

    subtrees) actually needs to use `git subtree`.

    ## External Dependencies (submodules)

    Building Rust will also use external git repositories tracked using [git

    submodules]. The complete list may be found in the [`.gitmodules`] file. Some

    of these projects are required (like `stdarch` for the standard library) and

    Building Rust will also use external git repositories tracked using [git submodules].

    The complete list may be found in the [`.gitmodules`] file.

    Some of these projects are required (like `stdarch` for the standard library) and

    some of them are optional (like `src/doc/book`).

    Usage of submodules is discussed more in the [Using Git chapter](git.md#git-submodules).

    Some of the submodules are allowed to be in a "broken" state where they

    either don't build or their tests don't pass, e.g. the documentation books

    like [The Rust Reference]. Maintainers of these projects will be notified

    when the project is in a broken state, and they should fix them as soon

    as possible. The current status is tracked on the [toolstate website].

    like [The Rust Reference].

    Maintainers of these projects will be notified

    when the project is in a broken state, and they should fix them as soon as possible.

    The current status is tracked on the [toolstate website].

    More information may be found on the Forge [Toolstate chapter].

    In practice, it is very rare for documentation to have broken toolstate.

    Breakage is not allowed in the beta and stable channels, and must be addressed

    before the PR is merged. They are also not allowed to be broken on `main` in

    the week leading up to the beta cut.

    before the PR is merged.

    They are also not allowed to be broken on `main` in the week leading up to the beta cut.

    [git submodules]: https://git-scm.com/book/en/v2/Git-Tools-Submodules

    [`.gitmodules`]: https://github.com/rust-lang/rust/blob/HEAD/.gitmodules

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

rustc-dev-guide subtree update #151029

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Uh oh!