Rollup of 12 pull requests
Successful merges:
- #136127 (Allow `*const W<dyn A> -> *const dyn A` ptr cast)
- #136968 (Turn order dependent trait objects future incompat warning into a hard error)
- #137319 (Stabilize `const_vec_string_slice`)
- #137885 (tidy: add triagebot checks)
- #138040 (compiler: Use `size_of` from the prelude instead of imported)
- #138084 (Use workspace lints for crates in `compiler/`)
- #138158 (Move more layouting logic to `rustc_abi`)
- #138160 (depend more on attr_data_structures and move find_attr! there)
- #138192 (crashes: couple more tests)
- #138216 (bootstrap: Fix stack printing when a step cycle is detected)
- #138232 (Reduce verbosity of GCC build log)
- #138242 (Revert "Don't test new error messages with the stage 0 compiler")
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: Fix stack printing when a step cycle is detected
When bootstrap detects a step dependency cycle (which represents a bootstrap bug), it is supposed to print out the contents of the step stack as part of its panic message.
However, while investigating #138205 it was found that bootstrap was actually printing out several copies of `Any { .. }`, because that is the Debug implementation for `dyn Any`. This is sadly not very helpful.
This PR fixes that problem by introducing a `trait AnyDebug: Any + Debug` that delegates to the underlying type's Debug implementation, while still allowing downcasting via Any.
---
The fixed behaviour can be verified manually (and is tested automatically) via a new dummy command, `./x run cyclic-step`:
```
$ x run cyclic-step
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.02s
thread 'main' panicked at src/bootstrap/src/core/builder/mod.rs:1521:17:
Cycle in build detected when adding CyclicStep { n: 0 }
CyclicStep { n: 0 }
CyclicStep { n: 1 }
CyclicStep { n: 2 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00
```
depend more on attr_data_structures and move find_attr! there
r? ``@oli-obk``
This should be an easy one. It just moves some imports around. This is necessary for other changes that I'm working on not to have import cycles. However, it's an easy one to just merge on its own.
Move more layouting logic to `rustc_abi`
Move all `LayoutData`-constructing code to `rustc_abi`:
- Infaillible operations get a new `LayoutData` constructor method;
- Faillible ones get a new method on `LayoutCalculator`.
compiler: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler.
These functions were added to all preludes in Rust 1.80.
r? ``@compiler-errors``
Change TaskDeps to start preallocated with 128 capacity
This is a tiny change that makes `TaskDeps::read_set` start preallocated with capacity for 128 elements.
From local profiling, it looks like `TaskDeps::read_set` is one of the most-often resized hash-sets in `rustc`.
add `tool::CargoClippy` and `tool::Cargofmt` binary to target sysroot
When running `x build clippy`, we expect `stage1-tool-bin/cargo-clippy` and `stage2/bin/cargo-clippy` to be the same, but they aren't. This happens because `tool::CargoClippy` doesn't place its binary in the `stage2` directory. As a result, `stage1-tool-bin/cargo-clippy` comes from `tool::CargoClippy`, while `stage2/bin/cargo-clippy` comes from `tool::Cargo`. Same applies for `tool::Cargofmt`.
This PR fixes the issue by adding `tool::CargoClippy` and ``tool::Cargofmt`` binaries to the expected sysroot and makes sure both directories share the same binary.
To test this, run `x build --stage 2 compiler clippy rustfmt`, link the stage2 sysroot with rustup, and then call `cargo +stage2 fmt` and `cargo +stage2 clippy` on any rust project (it wouldn't work without this PR).
Don't re-`assume` in `transmute`s that don't change niches
I noticed in nightly 2025-02-21 that `transmute` is emitting way more `assume`s than necessary for newtypes.
For example, the three transmutes in <https://rust.godbolt.org/z/fW1KaTc4o> emits
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
%0 = sub i32 %_1, 1
%1 = icmp ule i32 %0, -2
call void `@llvm.assume(i1` %1)
%2 = sub i32 %_1, 1
%3 = icmp ule i32 %2, -2
call void `@llvm.assume(i1` %3)
%4 = sub i32 %_1, 1
%5 = icmp ule i32 %4, -2
call void `@llvm.assume(i1` %5)
%6 = sub i32 %_1, 1
%7 = icmp ule i32 %6, -2
call void `@llvm.assume(i1` %7)
%8 = sub i32 %_1, 1
%9 = icmp ule i32 %8, -2
call void `@llvm.assume(i1` %9)
%10 = sub i32 %_1, 1
%11 = icmp ule i32 %10, -2
call void `@llvm.assume(i1` %11)
ret i32 %_1
}
```
But those are all just newtypes that don't change size or niches, so none of it's needed.
After this PR it's down to just
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
ret i32 %_1
}
```
because none of those `assume`s in the original actually did anything.
(Transmuting to something with a difference niche, though, still has the assumes -- the other tests continue to pass checking that.)
