rustc-dev-guide subtree update

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

@@ -45,14 +45,16 @@ fn main() -> Result<()> {
                 continue;
             }
             let old = fs::read_to_string(&path)?;
-            let new = lengthen_lines(&comply(&old), cli.line_length_limit);
+            let new = comply(&old);
             if new == old {
                 compliant.push(path.clone());
-            } else if cli.overwrite {
-                fs::write(&path, new)?;
-                made_compliant.push(path.clone());
             } else {
-                not_compliant.push(path.clone());
+                if cli.overwrite {
+                    fs::write(&path, lengthen_lines(&new, cli.line_length_limit))?;
+                    made_compliant.push(path.clone());
+                } else {
+                    not_compliant.push(path.clone());
+                }
             }
         }
     }

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

@@ -1 +1 @@
-f53b654a8882fd5fc036c4ca7a4ff41ce32497a6
+f2b291d902bfde7d7f209fc3a64908134bcef201

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

@@ -6,7 +6,7 @@ For the meantime, you can download up-to-date builds to enable `std::autodiff` o
 **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.
+In the past you could also download builds for **Apple** (aarch64-apple), however they are not usable at the moment.
 
 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.
@@ -24,7 +24,7 @@ For now, you'll have to manually download and copy 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`].
+Please (currently) build it from source.
 
 ## Installation guide for Nix user.
 
@@ -111,8 +111,7 @@ docker cp <dockerid>:/rust/build/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.
 Afterwards we can create a new (pre-release) tag on the EnzymeAD/rust repository and make a PR against the EnzymeAD/enzyme-explorer repository to update the tag.
 Remember to ping `tgymnich` on the PR to run his update script.
 Note: We should archive EnzymeAD/rust and update the instructions here.
-The explorer should soon
-be able to get the rustc toolchain from the official rust servers.
+The explorer should soon be able to get the rustc toolchain from the official rust servers.
 
 
 ## Build instruction for Enzyme itself
@@ -144,5 +143,4 @@ This will build Enzyme, and you can find it in `Enzyme/enzyme/build/lib/<LLD/Cla
 (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/doc/rustc-dev-guide/src/building/build-install-distribution-artifacts.md

@@ -3,16 +3,17 @@
 You might want to build and package up the compiler for distribution.
 You’ll want to run this command to do it:
 
-```bash
+```console
 ./x dist
 ```
 
 # Install from source
 
 You might want to prefer installing Rust (and tools configured in your configuration)
-by building from source. If so, you want to run this command:
+by building from source.
+If so, you want to run this command:
 
-```bash
+```console
 ./x install
 ```
 
@@ -24,8 +25,9 @@ by building from source. If so, you want to run this command:
    invoke it with `rustc +foo ...` (where ... represents the rest of the arguments).
 
 Instead of installing Rust (and tools in your config file) globally, you can set `DESTDIR`
-environment variable to change the installation path. If you want to set installation paths
+environment variable to change the installation path.
+If you want to set installation paths
 more dynamically, you should prefer [install options] in your config file to achieve that.
 
 [create-rustup-toolchain]: ./how-to-build-and-run.md#creating-a-rustup-toolchain
-[install options]: https://github.com/rust-lang/rust/blob/f7c8928f035370be33463bb7f1cd1aeca2c5f898/config.example.toml#L422-L442
+[install options]: https://github.com/rust-lang/rust/blob/f7c8928f035370be33463bb7f1cd1aeca2c5f898/config.example.toml#L422-L442

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

@@ -197,7 +197,7 @@ The below steps needs to be followed in order to implement a new unstable featur
    For features introducing new syntax, pre-expansion gating should be used instead.
    During parsing, when the new syntax is parsed,
    the symbol must be inserted to the current crate's [`GatedSpans`]
-   via `self.sess.gated_span.gate(sym::my_feature, span)`.
+   via `self.psess.gated_spans.gate(sym::my_feature, span)`.
 
    After being inserted to the gated spans,
    the span must be checked in the [`rustc_ast_passes::feature_gate::check_crate`] function,

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

@@ -39,7 +39,15 @@ This gives you a working LLVM build.
 
 
 ## Testing
-run
+Run this test script for offload-specific tests:
 ```console
 ./x test --stage 1 tests/codegen-llvm/gpu_offload
 ```
+
+For testing the CI locally, you may use the commands outlined in [Testing with Docker](https://rustc-dev-guide.rust-lang.org/tests/docker.html):
+```console
+cargo run --manifest-path src/ci/citool/Cargo.toml run-local dist-x86_64-linux
+```
+This stores all compiler artifacts in the `obj` directory, however should you modify rustc-specific code, you may need to delete this directory as the Docker image will cache its state otherwise.
+
+Submodules should also be checked out at this point.

src/doc/rustc-dev-guide/src/tests/compiletest.md

@@ -832,13 +832,14 @@ check for any problems that might arise.
 To run the tests in a different mode, you need to pass the `--compare-mode` CLI flag:
 
 ```bash
-./x test tests/ui --compare-mode=chalk
+./x test tests/ui --compare-mode=next-solver
 ```
 
 The possible compare modes are:
 
-- `polonius` — Runs with Polonius with `-Zpolonius`.
-- `chalk` — Runs with Chalk with `-Zchalk`.
+- `polonius` — Runs with Polonius with `-Zpolonius=next`.
+- `next-solver` — Runs with the next trait solver with `-Znext-solver`.
+- `next-solver-coherence` — Runs coherence with the next trait solver with `-Znext-solver=coherence`.
 - `split-dwarf` — Runs with unpacked split-DWARF with `-Csplit-debuginfo=unpacked`.
 - `split-dwarf-single` — Runs with packed split-DWARF with `-Csplit-debuginfo=packed`.
 

src/doc/rustc-dev-guide/src/tests/directives.md

@@ -148,7 +148,8 @@ Some examples of `X` in `ignore-X` or `only-X`:
 - When particular debuggers are being tested: `cdb`, `gdb`, `lldb`
 - When particular debugger versions are matched: `ignore-gdb-version`
 - When the [parallel frontend] is enabled: `ignore-parallel-frontend`
-- Specific [compare modes]: `compare-mode-polonius`, `compare-mode-chalk`,
+- Specific [compare modes]: `compare-mode-polonius`,
+  `compare-mode-next-solver`, `compare-mode-next-solver-coherence`,
   `compare-mode-split-dwarf`, `compare-mode-split-dwarf-single`
 - The two different test modes used by coverage tests:
   `ignore-coverage-map`, `ignore-coverage-run`

src/doc/rustc-dev-guide/src/unsafety-checking.md

@@ -1,47 +1,50 @@
 # Unsafety checking
 
 Certain expressions in Rust can violate memory safety and as such need to be
-inside an `unsafe` block or function. The compiler will also warn if an unsafe
-block is used without any corresponding unsafe operations.
+inside an `unsafe` block or function.
+The compiler will also warn if an unsafe block is used without any corresponding unsafe operations.
 
 ## Overview
 
-The unsafety check is located in the [`check_unsafety`] module. It performs a
-walk over the [THIR] of a function and all of its closures and inline constants.
+The unsafety check is located in the [`check_unsafety`] module.
+It performs a walk over the [THIR] of a function and all of its closures and inline constants.
 It keeps track of the unsafe context: whether it has entered an `unsafe` block.
-If an unsafe operation is used outside of an `unsafe` block, then an error is
-reported. If an unsafe operation is used in an unsafe block then that block is
-marked as used for [the unused_unsafe lint](#the-unused_unsafe-lint).
+If an unsafe operation is used outside of an `unsafe` block, then an error is reported.
+If an unsafe operation is used in an unsafe block,
+that block is marked as used for [the unused_unsafe lint](#the-unused_unsafe-lint).
 
-The unsafety check needs type information so could potentially be done on the
-HIR, making use of typeck results, THIR or MIR. THIR is chosen because there are
+The unsafety check needs type information, so could potentially be done on the
+HIR, making use of typeck results, THIR or MIR.
+THIR is chosen because there are
 fewer cases to consider than in HIR, for example unsafe function calls and
-unsafe method calls have the same representation in THIR. The check is not done
-on MIR because safety checks do not depend on control flow so MIR is not
-necessary to use and MIR doesn't have as precise spans for some expressions.
+unsafe method calls have the same representation in THIR.
+The check is not done on MIR because safety checks do not depend on control flow,
+so there is no need to use MIR.
+Also, MIR doesn't have precise enough spans for some expressions.
 
 Most unsafe operations can be identified by checking the `ExprKind` in THIR and
-checking the type of the argument. For example, dereferences of a raw pointer
+checking the type of the argument.
+For example, dereferences of a raw pointer
 correspond to `ExprKind::Deref`s with an argument that has a raw pointer type.
 
 Looking for unsafe Union field accesses is a bit more complex because writing to
-a field of a union is safe. The checker tracks when it's visiting the left-hand
+a field of a union is safe.
+The checker tracks when it's visiting the left-hand
 side of an assignment expression and allows union fields to directly appear
-there, while erroring in all other cases. Union field accesses can also occur
-in patterns, so those have to be walked as well.
+there, while erroring in all other cases.
+Union field accesses can also occur in patterns, so those have to be walked as well.
 
 [THIR]: ./thir.md
 [`check_unsafety`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/check_unsafety/index.html
 
 ## The unused_unsafe lint
 
-The unused_unsafe lint reports `unsafe` blocks that can be removed. The unsafety
-checker records whenever it finds an operation that requires unsafe. The lint is
-then reported if either:
+The unused_unsafe lint reports `unsafe` blocks that can be removed.
+The unsafety checker records whenever it finds an operation that requires unsafe.
+The lint is then reported if either:
 
 - An `unsafe` block contains no unsafe operations
-- An `unsafe` block is within another unsafe block, and the outer block
-  isn't considered unused
+- An `unsafe` block is within another unsafe block, and the outer block isn't considered unused
 
 ```rust
 #![deny(unused_unsafe)]
@@ -64,7 +67,8 @@ unsafe {
 ## Other checks involving `unsafe`
 
 [Unsafe traits] require an `unsafe impl` to be implemented, the check for this
-is done as part of [coherence]. The `unsafe_code` lint is run as a lint pass on
+is done as part of [coherence].
+The `unsafe_code` lint is run as a lint pass on
 the ast that searches for unsafe blocks, functions and implementations, as well
 as certain unsafe attributes.