about summary refs log tree commit diff
path: root/compiler/rustc_session/src/errors.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2024-02-14 10:07:01 +0000
committerbors <bors@rust-lang.org>2024-02-14 10:07:01 +0000
commit81b757c670483604c5ad04370bc505ba3d21356a (patch)
tree85b37aa43f3b13816e1ae13e634775d0a1c66acd /compiler/rustc_session/src/errors.rs
parentbb89df6903539e7014b8db29bccd6a9ee9553122 (diff)
parent6b9289c0862fa86ff3fcafe05011abb42c677e6f (diff)
downloadrust-81b757c670483604c5ad04370bc505ba3d21356a.tar.gz
rust-81b757c670483604c5ad04370bc505ba3d21356a.zip
Auto merge of #100603 - tmandry:zst-guards, r=dtolnay
Optimize away poison guards when std is built with panic=abort

> **Note**: To take advantage of this PR, you will have to use `-Zbuild-std` or build your own toolchain. rustup toolchains always link to a libstd that was compiled with `panic=unwind`, since it's compatible with `panic=abort` code.

When std is compiled with `panic=abort` we can remove a lot of the poison machinery from the locks. This changes the `Flag` and `Guard` types to be ZSTs. It also adds an uninhabited member to `PoisonError` so the compiler knows it can optimize away the `Result::Err` paths, and make `LockResult<T>` layout-equivalent to `T`.

### Is this a breaking change?

`PoisonError::new` now panics if invoked from a libstd built with `panic="abort"` (or any non-`unwind` strategy). It is unclear to me whether to consider this a breaking change.

In order to encounter this behavior, **both of the following must be true**:

#### Using a libstd with `panic="abort"`

This is pretty uncommon. We don't build libstd with that in rustup, except in (Tier 2-3) platforms that do not support unwinding, **most notably wasm**.

Most people who do this are using cargo's `-Z build-std` feature, which is unstable.

`panic="abort"` is not a supported option in Rust's build system. It is possible to configure it using `CARGO_TARGET_xxx_RUSTFLAGS`, but I believe this only works on **non-host** platforms.

#### Creating `PoisonError` manually

This is also unlikely. The only common use case I can think of is in tests, and you can't run tests with `panic="abort"` without the unstable `-Z panic_abort_tests` flag.

It's possible that someone is implementing their own locks using std's `PoisonError` **and** defining "thread failure" to mean something other than "panic". If this is the case then we would break their code if it was used with a `panic="abort"` libstd. The locking crates I know of don't replicate std's poison API, but I haven't done much research into this yet.

I've touched on a fair number of considerations here. Which ones do people consider relevant?
Diffstat (limited to 'compiler/rustc_session/src/errors.rs')
0 files changed, 0 insertions, 0 deletions