Merge ref 'e4fdb554ad2c' from rust-lang/rust

Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: rust-lang/rust@e4fdb55
Filtered ref: rust-lang/stdarch@ae05da8
Upstream diff: rust-lang/rust@eda4fc7...e4fdb55

This merge was created using https://github.com/rust-lang/josh-sync.

Author: The rustc-josh-sync Cronjob Bot

ci/sembr/src/main.rs

@@ -15,7 +15,7 @@ struct Cli {
     /// Modify files that do not comply
     overwrite: bool,
     /// Applies to lines that are to be split
-    #[arg(long, default_value_t = 100)]
+    #[arg(long, default_value_t = 80)]
     line_length_limit: usize,
 }
 

rust-version

@@ -1 +1 @@
-c78a29473a68f07012904af11c92ecffa68fcc75
+562dee4820c458d823175268e41601d4c060588a

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

@@ -1,12 +1,16 @@
 # Updating LLVM
 
-<!-- date-check: Aug 2024 -->
 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
@@ -86,7 +90,6 @@ An example PR: [#59089](https://github.com/rust-lang/rust/pull/59089)
 
 ## New LLVM Release Updates
 
-<!-- date-check: Jul 2023 -->
 
 Unlike bugfixes,
 updating to a new release of LLVM typically requires a lot more work.
@@ -167,12 +170,14 @@ so let's go through each in detail.
    You'll change at least
    `src/llvm-project` and will likely also change [`llvm-wrapper`] as well.
 
-   <!-- date-check: mar 2025 -->
+   <!-- date-check: March 2026 -->
    > For prior art, here are some previous LLVM updates:
    > - [LLVM 17](https://github.com/rust-lang/rust/pull/115959)
    > - [LLVM 18](https://github.com/rust-lang/rust/pull/120055)
    > - [LLVM 19](https://github.com/rust-lang/rust/pull/127513)
    > - [LLVM 20](https://github.com/rust-lang/rust/pull/135763)
+   > - [LLVM 21](https://github.com/rust-lang/rust/pull/143684)
+   > - [LLVM 22](https://github.com/rust-lang/rust/pull/150722)
 
    Note that sometimes it's easiest to land [`llvm-wrapper`] compatibility as a PR
    before actually updating `src/llvm-project`.

src/borrow-check/region-inference/member-constraints.md

@@ -1,17 +1,18 @@
 # Member constraints
 
 A member constraint `'m member of ['c_1..'c_N]` expresses that the
-region `'m` must be *equal* to some **choice regions** `'c_i` (for
-some `i`). These constraints cannot be expressed by users, but they
-arise from `impl Trait` due to its lifetime capture rules. Consider a
-function such as the following:
+region `'m` must be *equal* to some **choice regions** `'c_i` (for some `i`).
+These constraints cannot be expressed by users, but they
+arise from `impl Trait` due to its lifetime capture rules.
+Consider a function such as the following:
 
 ```rust,ignore
 fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. }
 ```
 
 Here, the true return type (often called the "hidden type") is only
-permitted to capture the lifetimes `'a` or `'b`. You can kind of see
+permitted to capture the lifetimes `'a` or `'b`.
+You can kind of see
 this more clearly by desugaring that `impl Trait` return type into its
 more explicit form:
 
@@ -23,16 +24,17 @@ fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { .. }
 Here, the idea is that the hidden type must be some type that could
 have been written in place of the `impl Trait<'x, 'y>` -- but clearly
 such a type can only reference the regions `'x` or `'y` (or
-`'static`!), as those are the only names in scope. This limitation is
+`'static`!), as those are the only names in scope.
+This limitation is
 then translated into a restriction to only access `'a` or `'b` because
 we are returning `MakeReturn<'a, 'b>`, where `'x` and `'y` have been
 replaced with `'a` and `'b` respectively.
 
 ## Detailed example
 
 To help us explain member constraints in more detail, let's spell out
-the `make` example in a bit more detail. First off, let's assume that
-you have some dummy trait:
+the `make` example in a bit more detail.
+First off, let's assume that you have some dummy trait:
 
 ```rust,ignore
 trait Trait<'a, 'b> { }
@@ -49,8 +51,8 @@ fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> {
 ```
 
 What happens in this case is that the return type will be `(&'0 u32, &'1 u32)`,
-where `'0` and `'1` are fresh region variables. We will have the following
-region constraints:
+where `'0` and `'1` are fresh region variables.
+We will have the following region constraints:
 
 ```txt
 '0 live at {L}
@@ -67,11 +69,11 @@ return tuple is constructed to where it is returned (in fact, `'0` and
 `'1` might have slightly different liveness sets, but that's not very
 interesting to the point we are illustrating here).
 
-The `'a: '0` and `'b: '1` constraints arise from subtyping. When we
-construct the `(a, b)` value, it will be assigned type `(&'0 u32, &'1
+The `'a: '0` and `'b: '1` constraints arise from subtyping.
+When we construct the `(a, b)` value, it will be assigned type `(&'0 u32, &'1
 u32)` -- the region variables reflect that the lifetimes of these
-references could be made smaller. For this value to be created from
-`a` and `b`, however, we do require that:
+references could be made smaller.
+For this value to be created from `a` and `b`, however, we do require that:
 
 ```txt
 (&'a u32, &'b u32) <: (&'0 u32, &'1 u32)
@@ -82,35 +84,39 @@ which means in turn that `&'a u32 <: &'0 u32` and hence that `'a: '0`
 
 Note that if we ignore member constraints, the value of `'0` would be
 inferred to some subset of the function body (from the liveness
-constraints, which we did not write explicitly). It would never become
+constraints, which we did not write explicitly).
+It would never become
 `'a`, because there is no need for it too -- we have a constraint that
-`'a: '0`, but that just puts a "cap" on how *large* `'0` can grow to
-become. Since we compute the *minimal* value that we can, we are happy
-to leave `'0` as being just equal to the liveness set. This is where
-member constraints come in.
+`'a: '0`, but that just puts a "cap" on how *large* `'0` can grow to become.
+Since we compute the *minimal* value that we can, we are happy
+to leave `'0` as being just equal to the liveness set.
+This is where member constraints come in.
 
 ## Choices are always lifetime parameters
 
 At present, the "choice" regions from a member constraint are always lifetime
-parameters from the current function. As of <!-- date-check --> October 2021,
+parameters from the current function. As of <!-- date-check --> March 2026,
 this falls out from the placement of impl Trait, though in the future it may not
-be the case. We take some advantage of this fact, as it simplifies the current
-code. In particular, we don't have to consider a case like `'0 member of ['1,
+be the case.
+We take some advantage of this fact, as it simplifies the current code.
+In particular, we don't have to consider a case like `'0 member of ['1,
 'static]`, in which the value of both `'0` and `'1` are being inferred and hence
-changing. See [rust-lang/rust#61773][#61773] for more information.
+changing.
+See [rust-lang/rust#61773][#61773] for more information.
 
 [#61773]: https://github.com/rust-lang/rust/issues/61773
 
 ## Applying member constraints
 
-Member constraints are a bit more complex than other forms of
-constraints. This is because they have a "or" quality to them -- that
+Member constraints are a bit more complex than other forms of constraints.
+This is because they have a "or" quality to them -- that
 is, they describe multiple choices that we must select from. E.g., in
 our example constraint `'0 member of ['a, 'b, 'static]`, it might be
-that `'0` is equal to `'a`, `'b`, *or* `'static`. How can we pick the
-correct one?  What we currently do is to look for a *minimal choice*
--- if we find one, then we will grow `'0` to be equal to that minimal
-choice. To find that minimal choice, we take two factors into
+that `'0` is equal to `'a`, `'b`, *or* `'static`.
+How can we pick the correct one?
+What we currently do is to look for a *minimal choice*
+-- if we find one, then we will grow `'0` to be equal to that minimal choice.
+To find that minimal choice, we take two factors into
 consideration: lower and upper bounds.
 
 ### Lower bounds
@@ -121,30 +127,34 @@ apply member constraints, we've already *computed* the lower bounds of
 `'0` because we computed its minimal value (or at least, the lower
 bounds considering everything but member constraints).
 
-Let `LB` be the current value of `'0`. We know then that `'0: LB` must
-hold, whatever the final value of `'0` is. Therefore, we can rule out
+Let `LB` be the current value of `'0`.
+We know then that `'0: LB` must hold, whatever the final value of `'0` is.
+Therefore, we can rule out
 any choice `'choice` where `'choice: LB` does not hold.
 
-Unfortunately, in our example, this is not very helpful. The lower
-bound for `'0` will just be the liveness set `{L}`, and we know that
-all the lifetime parameters outlive that set. So we are left with the
-same set of choices here. (But in other examples, particularly those
+Unfortunately, in our example, this is not very helpful.
+The lower bound for `'0` will just be the liveness set `{L}`, and we know that
+all the lifetime parameters outlive that set.
+So we are left with the same set of choices here.
+(But in other examples, particularly those
 with different variance, lower bound constraints may be relevant.)
 
 ### Upper bounds
 
 The *upper bounds* are those lifetimes that *must outlive* `'0` --
 i.e., that `'0` must be *smaller* than. In our example, this would be
-`'a`, because we have the constraint that `'a: '0`. In more complex
-examples, the chain may be more indirect.
+`'a`, because we have the constraint that `'a: '0`.
+In more complex examples, the chain may be more indirect.
 
 We can use upper bounds to rule out members in a very similar way to
-lower bounds. If UB is some upper bound, then we know that `UB:
+lower bounds.
+If UB is some upper bound, then we know that `UB:
 '0` must hold, so we can rule out any choice `'choice` where `UB:
 'choice` does not hold.
 
 In our example, we would be able to reduce our choice set from `['a,
-'b, 'static]` to just `['a]`. This is because `'0` has an upper bound
+'b, 'static]` to just `['a]`.
+This is because `'0` has an upper bound
 of `'a`, and neither `'a: 'b` nor `'a: 'static` is known to hold.
 
 (For notes on how we collect upper bounds in the implementation, see
@@ -153,39 +163,45 @@ of `'a`, and neither `'a: 'b` nor `'a: 'static` is known to hold.
 ### Minimal choice
 
 After applying lower and upper bounds, we can still sometimes have
-multiple possibilities. For example, imagine a variant of our example
-using types with the opposite variance. In that case, we would have
-the constraint `'0: 'a` instead of `'a: '0`. Hence the current value
-of `'0` would be `{L, 'a}`. Using this as a lower bound, we would be
+multiple possibilities.
+For example, imagine a variant of our example
+using types with the opposite variance.
+In that case, we would have the constraint `'0: 'a` instead of `'a: '0`.
+Hence the current value of `'0` would be `{L, 'a}`.
+Using this as a lower bound, we would be
 able to narrow down the member choices to `['a, 'static]` because `'b:
-'a` is not known to hold (but `'a: 'a` and `'static: 'a` do hold). We
-would not have any upper bounds, so that would be our final set of choices.
+'a` is not known to hold (but `'a: 'a` and `'static: 'a` do hold).
+We would not have any upper bounds, so that would be our final set of choices.
 
 In that case, we apply the **minimal choice** rule -- basically, if
-one of our choices if smaller than the others, we can use that. In
-this case, we would opt for `'a` (and not `'static`).
+one of our choices if smaller than the others, we can use that.
+In this case, we would opt for `'a` (and not `'static`).
 
 This choice is consistent with the general 'flow' of region
 propagation, which always aims to compute a minimal value for the
-region being inferred. However, it is somewhat arbitrary.
+region being inferred.
+However, it is somewhat arbitrary.
 
 <a id="collecting"></a>
 
 ### Collecting upper bounds in the implementation
 
 In practice, computing upper bounds is a bit inconvenient, because our
-data structures are setup for the opposite. What we do is to compute
+data structures are setup for the opposite.
+What we do is to compute
 the **reverse SCC graph** (we do this lazily and cache the result) --
-that is, a graph where `'a: 'b` induces an edge `SCC('b) ->
-SCC('a)`. Like the normal SCC graph, this is a DAG. We can then do a
-depth-first search starting from `SCC('0)` in this graph. This will
-take us to all the SCCs that must outlive `'0`.
+that is, a graph where `'a: 'b` induces an edge `SCC('b) -> SCC('a)`.
+Like the normal SCC graph, this is a DAG.
+We can then do a depth-first search starting from `SCC('0)` in this graph.
+This will take us to all the SCCs that must outlive `'0`.
 
 One wrinkle is that, as we walk the "upper bound" SCCs, their values
-will not yet have been fully computed. However, we **have** already
+will not yet have been fully computed.
+However, we **have** already
 applied their liveness constraints, so we have some information about
-their value. In particular, for any regions representing lifetime
+their value.
+In particular, for any regions representing lifetime
 parameters, their value will contain themselves (i.e., the initial
-value for `'a` includes `'a` and the value for `'b` contains `'b`). So
-we can collect all of the lifetime parameters that are reachable,
+value for `'a` includes `'a` and the value for `'b` contains `'b`).
+So we can collect all of the lifetime parameters that are reachable,
 which is precisely what we are interested in.

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/error-codes.md

@@ -10,7 +10,7 @@ Note that not all _historical_ (no longer emitted) error codes have explanations
 The explanations are written in Markdown (see the [CommonMark Spec] for
 specifics around syntax), and all of them are linked in the [`rustc_error_codes`] crate.
 Please read [RFC 1567] for details on how to format and write long error codes.
-As of <!-- date-check --> February 2023, there is an
+As of <!-- date-check --> March 2026, there is an
 effort[^new-explanations] to replace this largely outdated RFC with a new more flexible standard.
 
 Error explanations should expand on the error message and provide details about