16

It may be not a good idea or not idiomatic, but let's assume that for some reason a library relies on catch_unwind for its business logic.

Can I somehow warn (by failing the compilation with an error message?) a user of this library if they set panic = "abort" in Cargo.toml of their "terminal" crate?

I was thinking about checking some environment variable in build.rs but can't find any variables with this information.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
ozkriff
  • 1,269
  • 15
  • 23
  • 3
    How would this hypothetical library deal with the user calling `exit` or the process being killed via the OS? It's definitely not a good idea. – Shepmaster Aug 15 '18 at 14:31
  • 3
    It won't handle these situations at all I guess. That's one reason why such a library is not a good idea in practice - it's a theoretical question. – ozkriff Aug 15 '18 at 14:46
  • You may be able to check RUSTFLAGS in a build.rs https://doc.rust-lang.org/cargo/reference/environment-variables.html and try to amend `-C panic=$PROFILE` to `-C panic=unwind`, but I'm not sure it'd work. See the original PR for panic=abort: https://github.com/rust-lang/rust/pull/36794 – Linear Aug 15 '18 at 21:16
  • Note, I'm not advocating subtly altering behavior, my suspicion is it'll cause a linker error. – Linear Aug 15 '18 at 21:45
  • @LinearZoetrope `RUSTFLAGS` is for the user to pass through extra flags; it's not set in a typical build. As far as I know, Cargo doesn't tell the build script what flags it's passing to rustc. – Lambda Fairy Jun 02 '20 at 04:39

1 Answers1

4

You can use this unstable code in your binary or library to cause an error when -C panic=abort is specified:

#![feature(panic_unwind)]
extern crate panic_unwind;

Which causes this helpful error when the wrong panic strategy is used:

error: the linked panic runtime `panic_unwind` is not compiled with this crate's panic strategy `abort`

When the panic strategy is correct, the extern crate declaration is redundant, but does nothing. When the panic strategy is wrong, it causes a linking error since you can't have two different panic strategy crates in the same binary. Since this check happens when crates are linked, note that if a library is never actually used by the top-level crate, then the check isn't run. (but this is a good thing: if your library is unused, then there is no need for this check anyways!)

Also, this error happens very late in the compilation process, so while cargo build will error out, cargo check won't complain since cargo check doesn't check for linking errors for performance reasons.

Unfortunately, there doesn't seem to be a way to do this on the stable channel.

smitop
  • 4,770
  • 2
  • 20
  • 53