#[panic_handler] does not work with std.

[lachlansneff]

The #[panic_handler] attribute does not work when using the std library. Thus, there's no way for libraries to register custom panic handlers without resorting to a lazy_static or similar global initializer.

This seems like quite an oversight.

[Mark-Simulacrum]

cc @japaric -- I presume this is intentional, or at least a known limitation?

[japaric]

panic_handler was designed for no_std use. Programs that link to std already had an stable API to set a panic handler (e.g. std::panic::set_hook) when panic_handler was designed.

Besides, I'm not sure how you could get panic_handler to work with non-no_std crates. Let's say we add a Cargo feature to std to remove its panic_handler; what happens to the stable std::panic::set_hook API? Should it be cfg-ed away causing compiler errors on any existing crate that uses it? Should it become a no-op changing the semantics of existing crates that use it? Both options are breaking changes. Whether a breaking change like that is OK or not is a question for the libs team.

(Also, you don't want to put panic_handler in general-purpose libraries since you can only link one instance of panic_handler into an application; doing so would make these libraries non-composable, i.e. you'll get a compiler error if you try to use them together. The application top crate is the only place where you should use / select the panic_handler)

[lachlansneff]

Would crate-specific panic handlers be a possible solution to this?

[Centril]

@japaric

Should it become a no-op changing the semantics of existing crates that use it? Both options are breaking changes. Whether a breaking change like that is OK or not is a question for the libs team.

Any non-#[no_std] crate that annotates a function with #[panic_handler] will get errors about:

error[E0152]: duplicate lang item found: `panic_impl`.

Therefore we get to define the semantics if we want to. A reasonable way to do that would be similar to #[global_allocator], that is, the std crate will add a #[panic_handler] if none is specified by the user.

As for set_hook, it could simply abort if other solutions are not sensible. It's not a breaking change to the actual application that ends up running this since no such applications have hitherto existed.

The application top crate is the only place where you should use / select the panic_handler

I think it would be sensible to have crates for the express purpose of redefining panic_handler and nothing else.

[ghost]

I would like to see this too.

Using crates like color-backtrace is cumbersome because one has to put color_backtrace::install(); into the main function every time. Setting up tests is especially difficult because there is no main function.

I wish it was enough to just add the crate as a dependency.

[bjorn3]

The "#[panic_handler]" of libstd does more than just print a panic message and backtrace. It is also responsible for starting unwinding, which can't be done on stable in any other way. Because of this overriding #[panic_handler] is not useful for color-backtrace.