Commit Graph

43712 Commits

Author SHA1 Message Date
Matthias Krüger
89ee41cc4c
Rollup merge of #136847 - nnethercote:simplify-intra-crate-quals, r=oli-obk
Simplify intra-crate qualifiers.

The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name. (Exceptions are things like in macros where `crate::` doesn't work because the macro is used in multiple crates.)

This commit fixes a bunch of these weird qualifiers.

r? `@jieyouxu`
2025-02-11 18:04:49 +01:00
Matthias Krüger
8ade6baa12
Rollup merge of #136833 - workingjubilee:let-the-impossible-be-impossible, r=compiler-errors
compiler: die immediately instead of handling unknown target codegen

We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die.

This allows cleaning up our "error-handling" spread across 5 crates.
2025-02-11 18:04:44 +01:00
Matthias Krüger
2cb21fb015
Rollup merge of #136786 - compiler-errors:de-de-duplicate-blocks, r=oli-obk
Remove the deduplicate_blocks pass

I don't think this pass does anything. It's a lot of complexity for 🤷  amount of benefit.

r? oli-obk
2025-02-11 18:04:42 +01:00
Matthias Krüger
65d20f39f3
Rollup merge of #136239 - folkertdev:show-supported-register-classes, r=SparrowLii,jieyouxu
show supported register classes in error message

a simple diagnostic change that shows the supported register classes when an invalid one is found.

This information can be hard to find (especially for unstable targets), and this message now gives at least something to try or search for. I've followed the pattern for invalid clobber ABIs.

`@rustbot` label +A-inline-assembly
2025-02-11 18:04:34 +01:00
Matthias Krüger
09ee4e7b00
Rollup merge of #135677 - yotamofek:resolve-cleanups2, r=compiler-errors
Small `rustc_resolve` cleanups

1. Don't open-code `Reverse`
2. Use slice patterns where possible
2025-02-11 18:04:28 +01:00
Matthias Krüger
d719afdbd9
Rollup merge of #135285 - tbu-:pr_fix_typo4, r=GuillaumeGomez
it-self → itself, build-system → build system, type-alias → type alias
2025-02-11 18:04:22 +01:00
bors
69482e8e5a Auto merge of #136851 - jhpratt:rollup-ftijn95, r=jhpratt
Rollup of 11 pull requests

Successful merges:

 - #136606 (Fix long lines which rustfmt fails to format)
 - #136663 (Stabilize `NonZero::count_ones`)
 - #136672 (library: doc: core::alloc::Allocator: trivial typo fix)
 - #136704 (Improve examples for file locking)
 - #136721 (cg_llvm: Reduce visibility of some items outside the `llvm` module)
 - #136813 (rustc_target: Add the fp16 target feature for AArch32)
 - #136830 (fix i686-unknown-hurd-gnu x87 footnote)
 - #136832 (Fix platform support table for i686-unknown-uefi)
 - #136835 (Stop using span hack for contracts feature gating)
 - #136837 (Overhaul how contracts are lowered on fn-like bodies)
 - #136839 (fix ensure_monomorphic_enough)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-11 10:17:02 +00:00
Jacob Pratt
21303103c3
Rollup merge of #136839 - lukas-code:actually-monomorphic-enough, r=compiler-errors
fix ensure_monomorphic_enough

When polymorphization was still a thing, the visitor was used to only recurse into *used generic parameters* of function/closure/coroutine types and allow unused parameters (i.e. the polymorphized parameters) to remain generic.

When polymorphization got removed, this got changed to always treat all parameters as polymorphic and never recurse into them: https://github.com/rust-lang/rust/pull/133883/files#diff-210c59e321070d0ca4625c04e9fb064bf43ddc34082e7e33a7ee8a6c577e95afL44-L62

This is clearly wrong and can cause MIR opts to misbehave, for example this currently prints "false" in release mode:

```rust
#![feature(core_intrinsics)]

fn generic<T>() {}

const fn type_id_of_val<T: 'static>(_: &T) -> u128 {
    std::intrinsics::type_id::<T>()
}

fn cursed_is_i32<T: 'static>() -> bool {
    (const { type_id_of_val(&generic::<T>) } == const { type_id_of_val(&generic::<i32>) })
}

fn main() {
    dbg!(cursed_is_i32::<i32>());
}
```

This PR reverts to the old behavior of always treating all types that contain type parameters as too generic, like we used to do without `-Zpolymorphize` before.

~~I'm not including the above as a test case here, because I think there is little value in testing code paths that have been removed and this seems unlikely to regress in a way that would be caught by a regression test, but let me know if you disagree and want me to add a test anyway.~~
2025-02-11 01:02:44 -05:00
Jacob Pratt
4ae214b846
Rollup merge of #136837 - compiler-errors:contracts-body-lowering, r=celinval
Overhaul how contracts are lowered on fn-like bodies

Consolidates all of the contracts lowering logic into `lower_fn_body`, rather than having it be split between `lower_item_kind` and `lower_fn_body`. This should fix #136683.

r? celinval
2025-02-11 01:02:43 -05:00
Jacob Pratt
94bf32e719
Rollup merge of #136835 - compiler-errors:contracts-span-hack, r=celinval
Stop using span hack for contracts feature gating

The contracts machinery is a pretty straightforward case of an *external* feature using a (perma-unstable) *internal* feature within its implementation. There's no reason why it needs to be implemented any differently than other features by using global span tracking hacks to change whether the internals are gated behind the `contracts` or `contracts_internals` feature gate -- for the case of macro expansions we already have `allow_internal_unstable` for exactly this situation.

This PR changes the internal, perma-unstable AST syntax to use the `contracts_internals` gate always, and adjusts the macro expansion to use the right spans so that `allow_internal_unstable` works correctly.

As a follow-up, there's really no reason to have `contracts` be a *compiler feature* since it's at this point fully a *library feature*; the only reason it's a compiler feature today is so we can mark it as incomplete, but that seems like a weak reason. I didn't do anything in this PR for this.

r? ``@celinval``
2025-02-11 01:02:43 -05:00
Jacob Pratt
c49ffaf7eb
Rollup merge of #136813 - mrkajetanp:aarch32-fp16-target-feature, r=davidtwco
rustc_target: Add the fp16 target feature for AArch32

As in the commit description. The feature is already available in rustc for AArch64.
2025-02-11 01:02:41 -05:00
Jacob Pratt
6153a8dcea
Rollup merge of #136721 - dpaoliello:cleanllvm2, r=Zalathar
cg_llvm: Reduce visibility of some items outside the `llvm` module

Next piece of #135502

This reduces the visibility of items (other than those in the `llvm` module) so that dead code analysis will correctly identify unused items.
2025-02-11 01:02:40 -05:00
bors
c182ce9cbc Auto merge of #136845 - matthiaskrgr:rollup-ol4np4z, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #136107 (Introduce CoercePointeeWellformed for coherence checks at typeck stage)
 - #136155 (Enable sanitizers on MSVC CI jobs)
 - #136524 (Delay bug when method confirmation cannot upcast object pick of self)
 - #136584 (Prevent generic pattern types from being used in libstd)
 - #136603 (compiler: gate `extern "{abi}"` in ast_lowering)
 - #136821 (assign marcoieni and jdno to infra-ci PRs)
 - #136825 (Update books)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-11 05:27:49 +00:00
Nicholas Nethercote
af6020320d Simplify intra-crate qualifiers.
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name.
(Exceptions are things like in macros where `crate::` doesn't work
because the macro is used in multiple crates.)

This commit fixes a bunch of these weird qualifiers.
2025-02-11 14:59:13 +11:00
bors
ffa9afef18 Auto merge of #127541 - estebank:diff-suggestions, r=petrochenkov
Show diff suggestion format on verbose replacement

```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
  --> $DIR/attempted-access-non-fatal.rs:7:15
   |
LL |     let _ = 2.l;
   |               ^
   |
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
   |
LL -     let _ = 2.l;
LL +     let _ = 2.0f64;
   |
```

before:
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
  --> $DIR/attempted-access-non-fatal.rs:7:15
   |
LL |     let _ = 2.l;
   |               ^
   |
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
   |
LL +     let _ = 2.0f64;
   |               ~~~~
```
r? `@oli-obk`
2025-02-11 02:35:06 +00:00
Matthias Krüger
38f4c1f49a
Rollup merge of #136603 - workingjubilee:move-abi-versioning-into-ast, r=compiler-errors
compiler: gate `extern "{abi}"` in ast_lowering

I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.

It also abstracts away certain error messages instead of constantly repeating them.

A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.

r? ``@ghost``
2025-02-11 02:53:44 +01:00
Matthias Krüger
c92aae90e4
Rollup merge of #136584 - oli-obk:pattern-types-generic, r=BoxyUwU
Prevent generic pattern types from being used in libstd

Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature.

These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc).

cc #136574 (new tracking issue for the `generic_pattern_types` feature gate)

r? ``@lcnr``

cc ``@scottmcm`` ``@joshtriplett``
2025-02-11 02:53:44 +01:00
Matthias Krüger
66573926f2
Rollup merge of #136524 - compiler-errors:bad-pick, r=BoxyUwU
Delay bug when method confirmation cannot upcast object pick of self

Justification is on the test comment. Simply delays a bug that we were previously ICEing on.

cc ``@adetaylor`` since this is a `arbitrary_self_types` ICE.
2025-02-11 02:53:43 +01:00
Matthias Krüger
af3c51d849
Rollup merge of #136107 - dingxiangfei2009:coerce-pointee-wellformed, r=compiler-errors
Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix #135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

``@rustbot`` label F-derive_coerce_pointee
2025-02-11 02:53:42 +01:00
Lukas Markeffsky
c1da4f1d3c fix ensure_monomorphic_enough 2025-02-11 01:15:08 +01:00
Michael Goulet
4f18560d06 Don't ICE when failing to lower contracts for associated impl items 2025-02-10 21:38:31 +00:00
Esteban Küber
f0845adb0c Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
  --> $DIR/attempted-access-non-fatal.rs:7:15
   |
LL |     let _ = 2.l;
   |               ^
   |
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
   |
LL -     let _ = 2.l;
LL +     let _ = 2.0f64;
   |
```
2025-02-10 20:21:39 +00:00
Michael Goulet
f78099e618 Fix imports, remove attrs for unused_* 2025-02-10 20:15:30 +00:00
Michael Goulet
28164e3c04 Stop using span hack for contracts feature gating 2025-02-10 19:51:26 +00:00
Jubilee Young
fd58652a7d cg_gcc: stop caring about compiling for unknown targets 2025-02-10 11:19:02 -08:00
Jubilee Young
17716be86e compiler: die immediately instead of handling unknown target codegen
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.

This allows cleaning up our "error-handling" spread across 5 crates.
2025-02-10 11:04:31 -08:00
Daniel Paoliello
5f29273921 rustc_codegen_llvm: Mark items as pub(crate) outside of the llvm module 2025-02-10 10:17:25 -08:00
Matthias Krüger
4fff3209df
Rollup merge of #136791 - nicholasbishop:bishop-disable-dwarf, r=jieyouxu
Disable DWARF in linker options for i686-unknown-uefi

This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table

See https://reviews.llvm.org/D69594 for details of where the warning was added.

This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.

The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.

Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
```

This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.

CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
2025-02-10 16:38:28 +01:00
Matthias Krüger
277dda4ed3
Rollup merge of #136731 - safinaskar:parallel-2025-02-08-07-22, r=SparrowLii
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"

rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"

We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive

cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349

r? SparrowLii

``@rustbot`` label: +WG-compiler-parallel

(rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
2025-02-10 16:38:27 +01:00
Matthias Krüger
ad92b850c6
Rollup merge of #136714 - tgross35:update-builtins, r=tgross35
Update `compiler-builtins` to 0.1.146

Exposes the error function so we can expose this in the standard library [1].

[1]: https://github.com/rust-lang/compiler-builtins/pull/753
2025-02-10 16:38:26 +01:00
Matthias Krüger
78f5bddd57
Rollup merge of #136419 - EnzymeAD:autodiff-tests, r=onur-ozkan,jieyouxu
adding autodiff tests

I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion?

Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as
`%0 = fadd fast double %x.0.val, %x.0.val`
(I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag)

r? ``@jieyouxu``

Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails.

Tracking:

- https://github.com/rust-lang/rust/issues/124509

Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
2025-02-10 16:38:23 +01:00
Jubilee
26ca716f79
Rollup merge of #136707 - clubby789:cmake-bisect, r=jieyouxu
Bump `cc` to v1.2.13 for the compiler workspace
2025-02-10 00:51:54 -08:00
Jubilee
ae732f3f65
Rollup merge of #136201 - davidv1992:eliminate-field-offset-alt, r=Mark-Simulacrum
Removed dependency on the field-offset crate, alternate approach

This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance.

r? ``@Mark-Simulacrum``
2025-02-10 00:51:50 -08:00
Jubilee
7f8108afc8
Rollup merge of #136053 - Zalathar:defer-counters, r=saethlin
coverage: Defer part of counter-creation until codegen

Follow-up to #135481 and #135873.

One of the pleasant properties of the new counter-assignment algorithm is that we can stop partway through the process, store the intermediate state in MIR, and then resume the rest of the algorithm during codegen. This lets it take into account which parts of the control-flow graph were eliminated by MIR opts, resulting in fewer physical counters and simpler counter expressions.

Those improvements end up completely obsoleting much larger chunks of code that were previously responsible for cleaning up the coverage metadata after MIR opts, while also doing a more thorough cleanup job.

(That change also unlocks some further simplifications that I've kept out of this PR to limit its scope.)
2025-02-10 00:51:49 -08:00
clubby789
09f57b2e5c Bump cc to v1.2.13 for the compiler workspace 2025-02-10 00:06:31 -08:00
Manuel Drehwald
061abbc369 remove outdated *First autodiff variants for higher-order ad 2025-02-10 01:35:53 -05:00
Manuel Drehwald
1221cff551 move second opt run to lto phase and cleanup code 2025-02-10 01:35:22 -05:00
bors
c03c38d5c2 Auto merge of #134740 - Flakebi:amdgpu-target, r=workingjubilee
Add amdgpu target

Add amdgpu target to rustc and enable the LLVM target.

Fix compiling `core` with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. `bitcast` is invalid for this
case, `addrspacecast` needs to be used.

Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an `addrspacecast` under the hood)
instead.

MCP: https://github.com/rust-lang/compiler-team/issues/823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
2025-02-10 05:18:36 +00:00
Jubilee Young
cd9d39e360 compiler: remove abi-specific extern "{abi}" suggestions
These are either residue of a long-term migration away from something,
or are simply trying too hard to be specifically useful:
nearest-match suggestions for ABI strings should handle this.
2025-02-09 20:45:47 -08:00
Jubilee Young
54ff6e0ad5 compiler: remove rustc_target::spec::abi reexports 2025-02-09 20:45:47 -08:00
Jubilee Young
90c50f0164 compiler: start using rustc_ast_lowering in rustc_passes 2025-02-09 20:45:47 -08:00
Jubilee Young
3f50076fb3 compiler: gate extern "{abi}" in ast_lowering
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.

It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
2025-02-09 20:36:59 -08:00
Ding Xiang Fei
aea5595c86
fix the error code document 2025-02-10 04:36:49 +08:00
Nicholas Bishop
9da96a65e1 Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer
> than 8 characters and will use a non-standard string table

See https://reviews.llvm.org/D69594 for details of where the warning was
added.

This warning only occurs with the i686 UEFI target, not x86_64 or
aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but
i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in
`i686_unknown_uefi.rs` for details of why.

The `.debug_frame` section should not actually be needed; UEFI targets
provide a separate PDB file for debugging. Disable DWARF (and by
extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.

Tested with:
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
2025-02-09 15:20:29 -05:00
Michael Goulet
a6dcfe3af4 Remove the deduplicate_blocks pass 2025-02-09 18:58:14 +00:00
Matthias Krüger
b5b460ddf1
Rollup merge of #136760 - chenyukang:fix-overflowing-int-lint-crash, r=oli-obk
Fix unwrap error in overflowing int literal

Fixes #136675

it's maybe `negative` only from [check_lit](526e3288fe/compiler/rustc_lint/src/types.rs (L546)), in this scenario the fields in `TypeLimits` is none.

r? ``@oli-obk``
2025-02-09 19:44:53 +01:00
Matthias Krüger
4b319bcada
Rollup merge of #136746 - wesleywiser:err_dwarf1, r=Urgau
Emit an error if `-Zdwarf-version=1` is requested

DWARF 1 is very different than DWARF 2+[^1] and LLVM does not really seem to support DWARF 1 as Clang does not offer a `-gdwarf-1` flag[^2] and `llc` will just generate DWARF 2 with the version set to 1[^3].

Since this isn't actually supported (and it's not clear it would be useful anyway), report that DWARF 1 is not supported if it is requested.

Also add a help message to the error saying which versions are supported.

cc #103057

[^1]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf
[^2]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gdwarf
[^3]: https://godbolt.org/z/s85d87n3a
2025-02-09 19:44:53 +01:00
Matthias Krüger
d64bd3bedd
Rollup merge of #136722 - kornelski:visit-spans, r=chenyukang
Visit all debug info in MIR Visitor

I've been experimenting with simplifying debug info in MIR inliner, and discovered that MIR Visitor doesn't reliably visit all spans. This PR adds the missing visitor calls.
2025-02-09 19:44:52 +01:00
Wesley Wiser
eea8ce5be4 Emit an error if -Zdwarf-version=1 is requested
DWARF 1 is very different than DWARF 2+ (see the commentary in
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf)
and LLVM does not really seem to support DWARF 1 as Clang does not offer
a `-gdwarf-1` flag and `llc` will just generate DWARF 2 with the version
set to 1: https://godbolt.org/z/s85d87n3a.

Since this isn't actually supported (and it's not clear it would be
useful anyway), report that DWARF 1 is not supported if it is requested.

Also add a help message to the error saying which versions are supported.
2025-02-09 10:05:13 -06:00
bors
124cc92199 Auto merge of #136751 - bjorn3:update_rustfmt, r=Mark-Simulacrum
Update bootstrap compiler and rustfmt

The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
2025-02-09 15:44:16 +00:00