Auto merge of #153770 - JonathanBrouwer:rollup-522Yrag, r=JonathanBrouwer

Rollup of 10 pull requests

Successful merges:

 - rust-lang/rust#153726 (Add optional CI job to build the compiler with the parallel frontend)
 - rust-lang/rust#153763 (Don't add empty target features for target-cpu=native on macOS)
 - rust-lang/rust#153432 (Fix some comments about dataflow analysis.)
 - rust-lang/rust#153529 (Fix LegacyKeyValueFormat report from docker build: pr)
 - rust-lang/rust#153694 (fix(query): Pass Query Key to `value_from_cycle_error`)
 - rust-lang/rust#153717 (unused_macro_rules switched used and unused comments)
 - rust-lang/rust#153736 (add test that an incomplete feature emits a warning)
 - rust-lang/rust#153748 (editorconfig: css uses tabs)
 - rust-lang/rust#153750 (rustc-dev-guide subtree update)
 - rust-lang/rust#153762 (actually make the is-fn test test what it says it tests)

Author: bors

rust-version

@@ -1 +1 @@
-c78a29473a68f07012904af11c92ecffa68fcc75
+eda4fc7733ee89e484d7120cafbd80dcb2fce66e

src/autodiff/installation.md

@@ -1,6 +1,50 @@
 # Installation
 
-In the near future, `std::autodiff` should become available in nightly builds for users. As a contributor however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you successfully build this project on a tier2/tier3 target.
+In the near future, `std::autodiff` should become available for users via rustup. As a rustc/enzyme/autodiff contributor however, you will still need to build rustc from source. 
+For the meantime, you can download up-to-date builds to enable `std::autodiff` on your latest nightly toolchain, if you are using either of:  
+**Linux**, with `x86_64-unknown-linux-gnu` or `aarch64-unknown-linux-gnu`  
+**Windows**, with `x86_64-llvm-mingw` or `aarch64-llvm-mingw`  
+
+You can also download slightly outdated builds for **Apple** (aarch64-apple), which should generally work for now. 
+
+If you need any other platform, you can build rustc including autodiff from source. Please open an issue if you want to help enabling automatic builds for your prefered target.
+
+## 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. If you want to download autodiff for apple, please look at the artifacts from this [`run`].
+
+## Installation guide for Nix user.
+
+This setup was recommended by a nix and autodiff user. It uses [`Overlay`]. Please verify for yourself if you are comfortable using that repository.
+In that case you might use the following nix configuration to get a rustc that supports `std::autodiff`.
+```nix
+{
+  enzymeLib = pkgs.fetchzip {
+    url = "https://ci-artifacts.rust-lang.org/rustc-builds/ec818fda361ca216eb186f5cf45131bd9c776bb4/enzyme-nightly-x86_64-unknown-linux-gnu.tar.xz";
+    sha256 = "sha256-Rnrop44vzS+qmYNaRoMNNMFyAc3YsMnwdNGYMXpZ5VY=";
+  };
+  
+  rustToolchain = pkgs.symlinkJoin {
+    name = "rust-with-enzyme";
+    paths = [pkgs.rust-bin.nightly.latest.default];
+    nativeBuildInputs = [pkgs.makeWrapper];
+    postBuild = ''
+      libdir=$out/lib/rustlib/x86_64-unknown-linux-gnu/lib
+      cp ${enzymeLib}/enzyme-preview/lib/rustlib/x86_64-unknown-linux-gnu/lib/libEnzyme-22.so $libdir/
+      wrapProgram $out/bin/rustc --add-flags "--sysroot $out"
+    '';
+  };
+}
+```
 
 ## Build instructions
 
@@ -87,3 +131,6 @@ ninja
 ```
 This will build Enzyme, and you can find it in `Enzyme/enzyme/build/lib/<LLD/Clang/LLVM/lib>Enzyme.so`. (Endings might differ based on your OS).
 
+[`Repo`]: https://github.com/rust-lang/rust/
+[`run`]: https://github.com/rust-lang/rust/pull/153026#issuecomment-3950046599
+[`Overlay`]: https://github.com/oxalica/rust-overlay

src/backend/updating-llvm.md

@@ -6,7 +6,12 @@ Rust supports building against multiple LLVM versions:
 * Tip-of-tree for the current LLVM development branch is usually supported within a few days.
   PRs for such fixes are tagged with `llvm-main`.
 * The latest released major version is always supported.
-* The one or two preceding major versions are usually supported.
+* The one or two preceding major versions are usually supported in the sense that they are expected
+  to build successfully and pass most tests.
+  However, fixes for miscompilations often do not get
+  backported to past LLVM versions, so using rustc with older versions of LLVM comes with an
+  increased risk of soundness bugs.
+  We strongly recommend using the latest version of LLVM.
 
 By default, Rust uses its own fork in the [rust-lang/llvm-project repository].
 This fork is based on a `release/$N.x` branch of the upstream project, where

src/building/how-to-build-and-run.md

@@ -110,7 +110,6 @@ Also, using `x` rather than `x.py` is recommended as:
 Notice that this is not absolute.
 For instance, using Nushell in VSCode on Win10,
 typing `x` or `./x` still opens `x.py` in an editor rather than invoking the program.
-:)
 
 In the rest of this guide, we use `x` rather than `x.py` directly.
 The following command:

src/conventions.md

@@ -139,6 +139,8 @@ if foo {
 }
 ```
 
+If you want to leave a note in the codebase, use `// FIXME` instead.
+
 <a id="cio"></a>
 
 ## Using crates from crates.io

src/diagnostics/translation.md

@@ -31,8 +31,7 @@ There are two ways of writing translatable diagnostics:
    ("Simple" diagnostics being those that don't require a lot of logic in
    deciding to emit subdiagnostics and can therefore be represented as diagnostic structs).
    See [the diagnostic and subdiagnostic structs documentation](./diagnostic-structs.md).
-2. Using typed identifiers with `Diag` APIs (in
-   `Diagnostic` or `Subdiagnostic` implementations).
+2. Using typed identifiers with `Diag` APIs (in `Diagnostic` or `Subdiagnostic` implementations).
 
 When adding or changing a translatable diagnostic,
 you don't need to worry about the translations.

src/feature-gate-check.md

@@ -8,7 +8,7 @@ nightly-only `#![feature(...)]` opt-in.
 This chapter documents the implementation
 of feature gating: where gates are defined, how they are enabled, and how usage is verified.
 
-<!-- data-check: Feb 2026 -->
+<!-- date-check: Feb 2026 -->
 
 ## Feature Definitions
 

src/git.md

@@ -383,6 +383,13 @@ Both the upside and downside of this is that it simplifies the history.
 On the one hand, you lose track of the steps in which changes were made, but
 the history becomes easier to work with.
 
+The easiest way to squash your commits in a PR on the `rust-lang/rust` repository is to use the `@bors squash` command in a comment on the PR.
+By default, [bors] combines all commit messages of the PR into the squashed commit message.
+To customize the commit message, use `@bors squash msg=<commit message>`.
+
+
+If you want to squash commits using local git operations, read on below.
+
 If there are no conflicts and you are just squashing to clean up the history,
 use `git rebase --interactive --keep-base main`.
 This keeps the fork point of your PR the same, making it easier to review the diff of what happened
@@ -410,11 +417,6 @@ because they only represent "fixups" and not real changes.
 For example,
 `git rebase --interactive HEAD~2` will allow you to edit the two commits only.
 
-For pull requests in `rust-lang/rust`, you can ask [bors] to squash by commenting
-`@bors squash` on the PR.
-By default, [bors] combines all commit messages in the PR.
-To customize the commit message, use `@bors squash [msg|message=<commit-message>]`.
-
 [bors]: https://github.com/rust-lang/bors
 
 ### `git range-diff`

src/query.md

@@ -90,7 +90,7 @@ dependencies of the local crate)
 Note that what determines the crate that a query is targeting is not the *kind* of query, but the *key*.
 For example, when you invoke `tcx.type_of(def_id)`, that could be a
 local query or an external query, depending on what crate the `def_id`
-is referring to (see the [`self::keys::Key`][Key] trait for more information on how that works).
+is referring to (see the [`self::keys::QueryKey`][QueryKey] trait for more information on how that works).
 
 Providers always have the same signature:
 
@@ -308,7 +308,7 @@ Let's go over these elements one by one:
   Also used as the name of a struct (`ty::queries::type_of`) that will be generated to represent
   this query.
 - **Query key type:** the type of the argument to this query.
-  This type must implement the [`ty::query::keys::Key`][Key] trait, which
+  This type must implement the [`ty::query::keys::QueryKey`][QueryKey] trait, which
   defines (for example) how to map it to a crate, and so forth.
 - **Result type of query:** the type produced by this query.
   This type should (a) not use `RefCell` or other interior mutability and (b) be
@@ -317,7 +317,7 @@ Let's go over these elements one by one:
 - **Query modifiers:** various flags and options that customize how the
   query is processed (mostly with respect to [incremental compilation][incrcomp]).
 
-[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/keys/trait.Key.html
+[QueryKey]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/keys/trait.QueryKey.html
 [incrcomp]: queries/incremental-compilation-in-detail.html#query-modifiers
 
 So, to add a query:

src/tests/ci.md

@@ -109,6 +109,12 @@ The live results can be seen on [the GitHub Actions workflows page].
 At any given time, at most a single `auto` build is being executed.
 Find out more in [Merging PRs serially with bors](#merging-prs-serially-with-bors).
 
+Normally, when an auto job fails, the whole CI workflow immediately ends. However, it can be useful to
+create auto jobs that are "non-blocking", or optional, to test them on CI for some time before blocking
+merges on them. This can be useful if those jobs can be flaky.
+
+To do that, prefix such a job with `optional-`, and set `continue_on_error: true` for it in [`jobs.yml`]. 
+
 [platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support
 [auto]: https://github.com/rust-lang/rust/tree/automation/bors/auto