Rollup of 6 pull requests
Successful merges:
- #137280 (stabilize ptr::swap_nonoverlapping in const)
- #140457 (Use target-cpu=z13 on s390x codegen const vector test)
- #140619 (Small adjustments to `check_attribute_safety` to make the logic more obvious)
- #140625 (Suggest `retain_mut` over `retain` as `Vec::extract_if` alternative)
- #140627 (Allow linking rustc and rustdoc against the same single tracing crate)
- #140630 (Async drop source info fix for proxy-drop-coroutine)
r? `@ghost`
`@rustbot` modify labels: rollup
Allow linking rustc and rustdoc against the same single tracing crate
Alternate title: _Ignore "a global default trace dispatcher has already been set" error in Rustdoc_
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes that these involve 2 different tracing crates.
I would like to be able to build rustdoc against the same tracing crate that rustc_log is also built against. Previously this arrangement would crash rustdoc:
```console
thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65:
called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set")
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: rustc_log::init_logger
4: rustc_driver_impl::init_logger
5: rustdoc::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md
note: please make sure that you have updated to the latest nightly
query stack during panic:
end of query stack
```
compiletest: Do not require annotations on empty labels and suggestions
Unlike other empty diagnostics, empty labels (only underlining spans) and empty suggestions (suggestions to remove something) are quite usual and do not require any special attention and annotations.
This effectively reverts a part of https://github.com/rust-lang/rust/pull/139485.
r? `@jieyouxu`
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes
that these involve 2 different tracing crates.
I would like to be able to build rustdoc against the same tracing crate
that rustc_log is also built against. Previously this arrangement would
crash rustdoc:
thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65:
called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set")
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: rustc_log::init_logger
4: rustc_driver_impl::init_logger
5: rustdoc::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md
note: please make sure that you have updated to the latest nightly
query stack during panic:
end of query stack
Remove backtrace dep from anyhow in features status dump tool
According to `anyhow`'s Cargo.toml:
> On compilers older than 1.65, features=["backtrace"] may be used to enable
> backtraces via the `backtrace` crate. This feature has no effect on 1.65+
> besides bringing in an unused dependency, as `std::backtrace` is always
> preferred.
So this is just bringing in an unused dependency.
rustdoc: Fix doctest heuristic for main fn wrapping
Fixes#140412 which regressed in #140220 that I reviewed. As mentioned in https://github.com/rust-lang/rust/pull/140220#issuecomment-2837061779, at the time I didn't have the time to re-review its latest changes and should've therefore invalided my previous "r=me" and blocked the PR on another review given the fragile nature of the doctest impl. This didn't happen which is my fault.
Contains some other small changes. Diff best reviewed modulo whitespace.
r? ``@GuillaumeGomez``
simd_select_bitmask: the 'padding' bits in the mask are just ignored
Fixes https://github.com/rust-lang/rust/issues/137942: we documented simd_select_bitmask to require the 'padding' bits in the mask (the mask can sometimes be longer than the vector; I am referring to these extra bits as 'padding' here) to be zero, mostly because nobody felt like doing the research for what should be done when they are non-zero. However, codegen is already perfectly happy just ignoring them, so in practice they can have any value. Some of the intrinsic wrappers in stdarch have trouble ensuring that they are zero. So let's just adjust the docs and Miri to permit non-zero 'padding' bits.
Cc ````@Amanieu```` ````@workingjubilee````
According to `anyhow`'s Cargo.toml:
> On compilers older than 1.65, features=["backtrace"] may be used to enable
> backtraces via the `backtrace` crate. This feature has no effect on 1.65+
> besides bringing in an unused dependency, as `std::backtrace` is always
> preferred.
So this is just bringing in an unused dependency.
rustfmt: Also allow bool literals as first item of let chain
This is a functional cherry-pick of https://github.com/rust-lang/rustfmt/pull/6492
I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization.
r? ````@ghost````
CI: rfl: move job forward to Linux v6.15-rc4
A hopefully routine upgrade to Linux v6.15-rc4!
r? `````@lqd````` `````@Kobzol`````
try-job: x86_64-rust-for-linux
`````@rustbot````` label A-rust-for-linux
`````@bors````` try
Add `rust.debug-assertions-tools` option
Before this PR, the two only options to configure the presence of debug assertions were the `rust.debug-assertions` and `rust.debug-assertions-std` options. The former applied to everything, and the latter allowed to override the setting just for the standard library. This combination of settings doesn't allow to enable debug assertions for the std and the compiler but not tools.
Some tools (like Cargo) are not really meant to be executed with debug assertions enabled, and in Ferrocene we hit some debug assertions in it that are exclusively meant for its test suite. We'd thus like to enable debug assertions everywhere but in tools.
This PR adds a `rust.debug-assertions-tools` setting that does exactly this.
