rustc-dev-guide subtree update

src/doc/rustc-dev-guide/ci/sembr/Cargo.lock

@@ -43,22 +43,22 @@ dependencies = [
 
 [[package]]
 name = "anstyle-query"
-version = "1.1.4"
+version = "1.1.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9e231f6134f61b71076a3eab506c379d4f36122f2af15a9ff04415ea4c3339e2"
+checksum = "40c48f72fd53cd289104fc64099abca73db4166ad86ea0b4341abe65af83dadc"
 dependencies = [
- "windows-sys 0.60.2",
+ "windows-sys",
 ]
 
 [[package]]
 name = "anstyle-wincon"
-version = "3.0.10"
+version = "3.0.11"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "3e0633414522a32ffaac8ac6cc8f748e090c5717661fddeea04219e2344f5f2a"
+checksum = "291e6a250ff86cd4a820112fb8898808a366d8f9f58ce16d1f538353ad55747d"
 dependencies = [
  "anstyle",
  "once_cell_polyfill",
- "windows-sys 0.60.2",
+ "windows-sys",
 ]
 
 [[package]]
@@ -347,7 +347,7 @@ version = "0.1.11"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "c2a7b1c03c876122aa43f3020e6c3c3ee5c05081c9a00739faf7503aeba10d22"
 dependencies = [
- "windows-sys 0.61.2",
+ "windows-sys",
 ]
 
 [[package]]
@@ -356,15 +356,6 @@ version = "0.2.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f0805222e57f7521d6a62e36fa9163bc891acd422f971defe97d64e70d0a4fe5"
 
-[[package]]
-name = "windows-sys"
-version = "0.60.2"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "f2f500e4d28234f72040990ec9d39e3a6b950f9f22d3dba18416c35882612bcb"
-dependencies = [
- "windows-targets",
-]
-
 [[package]]
 name = "windows-sys"
 version = "0.61.2"
@@ -373,68 +364,3 @@ checksum = "ae137229bcbd6cdf0f7b80a31df61766145077ddf49416a728b02cb3921ff3fc"
 dependencies = [
  "windows-link",
 ]
-
-[[package]]
-name = "windows-targets"
-version = "0.53.5"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "4945f9f551b88e0d65f3db0bc25c33b8acea4d9e41163edf90dcd0b19f9069f3"
-dependencies = [
- "windows-link",
- "windows_aarch64_gnullvm",
- "windows_aarch64_msvc",
- "windows_i686_gnu",
- "windows_i686_gnullvm",
- "windows_i686_msvc",
- "windows_x86_64_gnu",
- "windows_x86_64_gnullvm",
- "windows_x86_64_msvc",
-]
-
-[[package]]
-name = "windows_aarch64_gnullvm"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a9d8416fa8b42f5c947f8482c43e7d89e73a173cead56d044f6a56104a6d1b53"
-
-[[package]]
-name = "windows_aarch64_msvc"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "b9d782e804c2f632e395708e99a94275910eb9100b2114651e04744e9b125006"
-
-[[package]]
-name = "windows_i686_gnu"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "960e6da069d81e09becb0ca57a65220ddff016ff2d6af6a223cf372a506593a3"
-
-[[package]]
-name = "windows_i686_gnullvm"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "fa7359d10048f68ab8b09fa71c3daccfb0e9b559aed648a8f95469c27057180c"
-
-[[package]]
-name = "windows_i686_msvc"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "1e7ac75179f18232fe9c285163565a57ef8d3c89254a30685b57d83a38d326c2"
-
-[[package]]
-name = "windows_x86_64_gnu"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9c3842cdd74a865a8066ab39c8a7a473c0778a3f29370b5fd6b4b9aa7df4a499"
-
-[[package]]
-name = "windows_x86_64_gnullvm"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "0ffa179e2d07eee8ad8f57493436566c7cc30ac536a3379fdf008f47f6bb7ae1"
-
-[[package]]
-name = "windows_x86_64_msvc"
-version = "0.53.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "d6bbff5f0aada427a1e5a6da5f1f98158182f26556f345ac9e04d36d0ebed650"

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

@@ -1 +1 @@
-f2b291d902bfde7d7f209fc3a64908134bcef201
+c58275e0369d09fc3959b8ba87dcbcbe73797465

src/doc/rustc-dev-guide/src/autodiff/debugging.md

@@ -28,7 +28,7 @@ The actual numbers will depend on your code.
 To confirm that your previous step worked, we will use llvm's `opt` tool. Find your path to the opt binary, with a path similar to `<some_dir>/rust/build/<x86/arm/...-target-triple>/ci-llvm/bin/opt`. If you build LLVM from source, you'll likely need to replace `ci-llvm` with `build`. Also find `llvmenzyme-21.<so/dll/dylib>` path, similar to `/rust/build/target-triple/enzyme/build/enzyme/llvmenzyme-21`. Please keep in mind that llvm frequently updates it's llvm backend, so the version number might be higher (20, 21, ...). Once you have both, run the following command:
 
 ```sh
-<path/to/opt> out.ll -load-pass-plugin=/path/to/build/<target-triple>/stage1/lib/libEnzyme-21.so -passes="enzyme" -enzyme-strict-aliasing=0  -s
+<path/to/opt> out.ll -load-pass-plugin=/path/to/build/<target-triple>/stage1/lib/libEnzyme-21.so -passes="enzyme" -enzyme-strict-aliasing=0  -S
 ```
 This command might fail for future versions or on your system, in which case you should replace libEnzyme-21.so with LLVMEnzyme-21.so. Look at the Enzyme docs for instructions on how to build it. You might need to also adjust how to build your LLVM version.
 
@@ -41,7 +41,7 @@ If you fail to get the same error, please open an issue in the rust repository.
 First find your `llvm-extract` binary, it's in the same folder as your opt binary. then run:
 
 ```sh
-<path/to/llvm-extract> -s --func=<name> --recursive --rfunc="enzyme_autodiff*" --rfunc="enzyme_fwddiff*" --rfunc=<fnc_called_by_enzyme> out.ll -o mwe.ll 
+<path/to/llvm-extract> -S --func=<name> --recursive --rfunc="enzyme_autodiff*" --rfunc="enzyme_fwddiff*" --rfunc=<fnc_called_by_enzyme> out.ll -o mwe.ll
 ```
 
 This command creates `mwe.ll`, a minimal working example.

src/doc/rustc-dev-guide/src/autodiff/installation.md

@@ -13,18 +13,13 @@ Please open an issue if you want to help enabling automatic builds for your pref
 
 ## Installation guide
 
-If you want to use `std::autodiff` and don't plan to contribute PR's to the project, then we recommend to just use your existing nightly installation and download the missing component.
-In the future, rustup will be able to do it for you.
-For now, you'll have to manually download and copy it.
-
-1) On our github repository, find the last merged PR: [`Repo`]
-2) Scroll down to the lower end of the PR, where you'll find a rust-bors message saying `Test successful` with a `CI` link.
-3) Click on the `CI` link, and grep for your target. E.g. `dist-x86_64-linux` or `dist-aarch64-llvm-mingw` and click `Load summary`.
-4) Under the `CI artifacts` section, find the `enzyme-nightly` artifact, download, and unpack it.
-5) Copy the artifact (libEnzyme-22.so for linux, libEnzyme-22.dylib for apple, etc.), which should be in a folder named `enzyme-preview`, to your rust toolchain directory. E.g. for linux: `cp  ~/Downloads/enzyme-nightly-x86_64-unknown-linux-gnu/enzyme-preview/lib/rustlib/x86_64-unknown-linux-gnu/lib/libEnzyme-22.so ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib`
-
-Apple support was temporarily reverted, due to downstream breakages.
-Please (currently) build it from source.
+If you want to use `std::autodiff` on Linux or Windows and don't plan to contribute PR's to the project, then we recommend to just use your existing nightly installation and download the missing component. Please run:
+
+```console
+rustup +nightly component add enzyme
+```
+
+Apple support was temporarily reverted, due to downstream breakages. Please build it from source till we can re-enable it.
 
 ## Installation guide for Nix user.
 

src/doc/rustc-dev-guide/src/autodiff/internals.md

@@ -15,7 +15,7 @@ fn main() {
 }
 ```
 
-The detailed documentation for the `std::autodiff` module is available at [std::autodiff](https://doc.rust-lang.org/std/autodiff/index.html).
+The detailed documentation for the `std::autodiff` module is available at [std::autodiff](https://doc.rust-lang.org/nightly/std/autodiff/index.html).
 
 Differentiable programming is used in various fields like numerical computing, [solid mechanics][ratel], [computational chemistry][molpipx], [fluid dynamics][waterlily] or for Neural Network training via Backpropagation, [ODE solver][diffsol], [differentiable rendering][libigl], [quantum computing][catalyst], and climate simulations.
 
@@ -25,3 +25,12 @@ Differentiable programming is used in various fields like numerical computing, [
 [diffsol]: https://github.com/martinjrobins/diffsol
 [libigl]: https://github.com/alecjacobson/libigl-enzyme-example?tab=readme-ov-file#run
 [catalyst]: https://github.com/PennyLaneAI/catalyst
+
+
+`std::autodiff` is currently based on Enzyme, an LLVM based tool for automatic differentation. There are three main reasons for relying on compiler based autodiff:
+
+- **Usability**: Current autodiff crates do not support normal Rust programs. They either enforce a custom DSL, require the usage of library provided types (instead of e.g. slices or arrays), or are limited to scalar functions. Compiler based autodiff allows users to write normal Rust code, including arrays, slices, user-defined structs and enums, control flow, and more.
+- **Performance**: Most existing Rust autodiff approaches have a constant overhead per operation. This can easily be amortized for ML applications which have few expensive operations on large tensors. It is, however, often unacceptable for applications in the HPC or scientific computing field. By working on (optimized) LLVM IR, compiler based autodiff can achieve [significantly][Enzyme] better performance in those cases.
+- **Features**: By operating on such a low level and sharing the implementation with other LLVM based languages, we can leverage the large amount of work already done in the Enzyme project. For example, we can support Rust code calling MPI routines, or GPU code, including libraries like CuBLAS.
+
+[Enzyme]: https://dl.acm.org/doi/10.5555/3495724.3496770

src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md

@@ -279,6 +279,16 @@ Instead, you can build a specific component by providing its name, like this:
 If you choose the `library` profile when running `x setup`, you can omit `--stage 1` (it's the
 default).
 
+If you want to build a tool, you can use:
+
+```bash
+./x build src/tools/cargo
+```
+
+You can also check the [the section on tool tests][tool-tests-link].
+
+[tool-tests-link]: ../tests/intro.md#tool-tests
+
 ## Creating a rustup toolchain
 
 Once you have successfully built `rustc`, you will have created a bunch

src/doc/rustc-dev-guide/src/building/quickstart.md

@@ -40,6 +40,12 @@ compiler toolchain. You can use it with rustup by linking it.
 rustup toolchain link stage1 build/host/stage1
 ```
 
+**NOTE**: If you use `./x setup tools`, the default stage will be set to 2 instead of 1.
+Adjust your command accordingly:
+```sh
+rustup toolchain link stage2 build/host/stage2
+```
+
 Now you have a toolchain called `stage1` linked to your build. You can use it to
 test the compiler.
 

src/doc/rustc-dev-guide/src/contributing.md

@@ -255,6 +255,9 @@ It is also perfectly fine
 (and even encouraged!) to use the CI to test your changes if it can help your productivity.
 In particular, we don't recommend running the full `./x test` suite locally,
 since it takes a very long time to execute.
+See the [Testing with CI] chapter for using Rust's CI to test your changes.
+
+[Testing with CI]: https://rustc-dev-guide.rust-lang.org/tests/ci.html#testing-with-ci
 
 ### r+
 

src/doc/rustc-dev-guide/src/implementing-new-features.md

@@ -1,4 +1,3 @@
-<!-- date-check: Jul 2025 -->
 
 # Implementing new language features
 
@@ -191,7 +190,7 @@ The below steps needs to be followed in order to implement a new unstable featur
     If the feature gate is not set,
     you should either maintain the pre-feature behavior or raise an error,
     depending on what makes sense.
-    Errors should generally use [`rustc_session::parse::feature_err`].
+    Errors should generally use [`rustc_session::errors::feature_err`].
     For an example of adding an error, see [#81015].
 
    For features introducing new syntax, pre-expansion gating should be used instead.
@@ -221,7 +220,7 @@ The below steps needs to be followed in order to implement a new unstable featur
 
 [`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.GatedSpans.html
 [#81015]: https://github.com/rust-lang/rust/pull/81015
-[`rustc_session::parse::feature_err`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/fn.feature_err.html
+[`rustc_session::errors::feature_err`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/errors/fn.feature_err.html
 [`rustc_ast_passes::feature_gate::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_passes/feature_gate/fn.check_crate.html
 [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md
 [stability in code]: #stability-in-code

src/doc/rustc-dev-guide/src/macro-expansion.md

@@ -76,23 +76,21 @@ If we can't make progress in an iteration, this represents a compile error.
            an AST, which may produce parse errors.
          - During expansion, we create [`SyntaxContext`]s (hierarchy 2) (see
            [Hygiene][hybelow] below).
-         - These three passes happen one after another on every AST fragment
+         - These two passes happen one after another on every AST fragment
            freshly expanded from a macro:
            - [`NodeId`]s are assigned by [`InvocationCollector`].
              This also collects new macro calls from this new AST piece and
              adds them to the queue.
-           - ["Def paths"][defpath] are created and [`DefId`]s are
-             assigned to them by [`DefCollector`].
-           - Names are put into modules (from the resolver's point of
-             view) by [`BuildReducedGraphVisitor`].
+           - [`DefCollector`] creates ["Def paths"][defpath], assigns the
+             corresponding [`DefId`]s, and also builds the reduced graph
+             (putting names into modules from the resolver's point of view).
       3. After expanding a single macro and integrating its output, continue
          to the next iteration of [`fully_expand_fragment`][fef].
    5. If it's not resolved:
       1. Put the macro back in the queue.
       2. Continue to next iteration...
 
 [`AstFragment`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragment.html
-[`BuildReducedGraphVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/build_reduced_graph/struct.BuildReducedGraphVisitor.html
 [`DefCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/def_collector/struct.DefCollector.html
 [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html
 [`ExpnId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnId.html

src/doc/rustc-dev-guide/src/normalization.md

@@ -164,7 +164,6 @@ In this example:
 
 When interfacing with the type system it will often be the case that it's necessary to request a type be normalized. There are a number of different entry points to the underlying normalization logic and each entry point should only be used in specific parts of the compiler.
 
-<!-- date-check: May 2025 -->
 An additional complication is that the compiler is currently undergoing a transition from the old trait solver to the new trait solver.
 As part of this transition our approach to normalization in the compiler has changed somewhat significantly, resulting in some normalization entry points being "old solver only" slated for removal in the long-term once the new solver has stabilized.
 The transition can be tracked via the [WG-trait-system-refactor](https://github.com/rust-lang/rust/labels/WG-trait-system-refactor) label in Github.

src/doc/rustc-dev-guide/src/offload/usage.md

@@ -59,7 +59,7 @@ fn main() {
 
 #[inline(never)]
 unsafe fn kernel(x: *mut [f64; 256]) {
-    core::intrinsics::offload(_kernel_1, [256, 1, 1], [32, 1, 1], (x,))
+    core::intrinsics::offload(kernel_1, [256, 1, 1], [32, 1, 1], (x,))
 }
 
 #[cfg(target_os = "linux")]
@@ -77,30 +77,36 @@ pub extern "gpu-kernel" fn kernel_1(x: *mut [f64; 256]) {
 ```
 
 ## Compile instructions
-It is important to use a clang compiler build on the same llvm as rustc.
+It is important to use a clang compiler build on the same LLVM as rustc.
 Just calling clang without the full path will likely use your system clang, which probably will be incompatible.
 So either substitute clang/lld invocations below with absolute path, or set your `PATH` accordingly.
 
-First we generate the device (gpu) code.
-Replace the target-cpu with the right code for your gpu.
+First we generate the device (GPU) code.
+
+<div class="warning">
+
+Replace the `target-cpu` (gfx90a) with the right code for your GPU. These are often referred to as "LLVM target names"[^list].
+
+</div>
+
 ```
 RUSTFLAGS="-Ctarget-cpu=gfx90a --emit=llvm-bc,llvm-ir -Zoffload=Device -Csave-temps -Zunstable-options" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
 ```
 You might afterwards need to copy your target/release/deps/<lib_name>.bc to lib.bc for now, before the next step.
 
-Now we generate the host (cpu) code.
+Now we generate the host (CPU) code.
 ```
-RUSTFLAGS="--emit=llvm-bc,llvm-ir -Csave-temps -Zoffload=Host=/p/lustre1/drehwald1/prog/offload/r/target/amdgcn-amd-amdhsa/release/deps/host.out -Zunstable-options" cargo +offload build -r
+RUSTFLAGS="--emit=llvm-bc,llvm-ir -Csave-temps -Zoffload=Host=/p/lustre1/drehwald1/prog/offload/r/target/amdgcn-amd-amdhsa/release/deps/device.bin -Zunstable-options" cargo +offload build -r
 ```
-This call also does a lot of work and generates multiple intermediate files for llvm offload.
+This call also does a lot of work and generates multiple intermediate files for LLVM offload.
 While we integrated most offload steps into rustc by now, one binary invocation still remains for now:
 
 ```
 "clang-linker-wrapper" "--should-extract=gfx90a" "--device-compiler=amdgcn-amd-amdhsa=-g" "--device-compiler=amdgcn-amd-amdhsa=-save-temps=cwd" "--device-linker=amdgcn-amd-amdhsa=-lompdevice" "--host-triple=x86_64-unknown-linux-gnu" "--save-temps" "--linker-path=/ABSOlUTE_PATH_TO/rust/build/x86_64-unknown-linux-gnu/lld/bin/ld.lld" "--hash-style=gnu" "--eh-frame-hdr" "-m" "elf_x86_64" "-pie" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "bare" "/lib/../lib64/Scrt1.o" "/lib/../lib64/crti.o" "/ABSOLUTE_PATH_TO/crtbeginS.o" "-L/ABSOLUTE_PATH_TO/rust/build/x86_64-unknown-linux-gnu/llvm/bin/../lib/x86_64-unknown-linux-gnu" "-L/ABSOLUTE_PATH_TO/rust/build/x86_64-unknown-linux-gnu/llvm/lib/clang/21/lib/x86_64-unknown-linux-gnu" "-L/lib/../lib64" "-L/usr/lib64" "-L/lib" "-L/usr/lib" "target/<GPU_DIR>/release/host.o" "-lstdc++" "-lm" "-lomp" "-lomptarget" "-L/ABSOLUTE_PATH_TO/rust/build/x86_64-unknown-linux-gnu/llvm/lib" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc" "/ABSOLUTE_PATH_TO/crtendS.o" "/lib/../lib64/crtn.o"
 ```
 
 You can try to find the paths to those files on your system.
-However, I recommend to not fix the paths, but rather just re-generate them by copying a bare-mode openmp example and compiling it with your clang.
+However, I recommend to not fix the paths, but rather just re-generate them by copying a bare-mode OpenMP example and compiling it with your clang.
 By adding `-###` to your clang invocation, you can see the invidual steps.
 It will show multiple steps, just look for the clang-linker-wrapper example.
 Make sure to still include the path to the `host.o` file, and not whatever tmp file you got when compiling your c++ example with the following call.
@@ -121,3 +127,5 @@ To receive more information about the memory transfer, you can enable info print
 ```
 LIBOMPTARGET_INFO=-1  ./main
 ```
+
+[^list]: https://rocm.docs.amd.com/en/latest/reference/gpu-arch-specs.html or https://developer.nvidia.com/cuda/gpus. Alternatively, check `rustc --print target-cpus`.

src/doc/rustc-dev-guide/src/rustdoc-internals.md

@@ -222,7 +222,7 @@ directly, even during `HTML` generation.
 This [didn't used to be the case], and
 a lot of `rustdoc`'s architecture was designed around not doing that, but a
 `TyCtxt` is now passed to `formats::renderer::run_format`, which is used to
-run generation for both `HTML` and the (unstable as of <!-- date-check --> Nov 2025) JSON format.
+run generation for both `HTML` and the (unstable as of <!-- date-check --> May 2026) JSON format.
 
 This change has allowed other changes to remove data from the "clean" [`AST`][ast]
 that can be easily derived from `TyCtxt` queries, and we'll usually accept