Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications #44489
Description
Update(2018-08-28)
This is a tracking issue for the RFC "stable mechanism to specify the behavior of panic! in no-std applications " (rust-lang/rfcs#2070).
Steps:
- Implement the RFC
- Adjust documentation (see instructions on forge)
- The doc-comment of libcore mentions
rust_begin_panic
- The doc-comment of libcore mentions
- Stabilization PR (see instructions on forge)
Unresolved questions:
fmt::Display
Should the Display of PanicInfo format the panic information as "panicked at 'reason', src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as
"reason".
Unwinding in no-std
Is this design compatible, or can it be extended to work, with unwinding
implementations for no-std environments?
Issues to solve before stabilization
- panic_implementation: Error message still talks about the panic_fmt lang item when missing panic_implementation: Error message talks about the panic_impl lang item when missing #51341
- panic_implementation: no_mangle attribute needed? panic_implementation: no_mangle attribute needed? #51342
-
rust_begin_unwindnot emitted when crate-type = binrust_begin_unwindnot emitted when crate-type = bin #51671
Activity
whitequark commentedon Sep 12, 2017
As someone with a working unwinding implementation in a no_std environment (not with a Rust personality function though), I can answer this if someone summarizes the feature for me. I kind of lost track and I don't have time to get into every minor detail at the moment.
yodaldevoid commentedon Sep 14, 2017
Sorry to bring this off topic so soon, but could you explain this? I was under the impression that unless you wanted to implement unwinding in an ad-hoc way (e.g. doing unwinding during panic by explicitly calling some function) you had to implement the
eh_personalityfunction.whitequark commentedon Sep 14, 2017
I use unwinding in a language runtime. The language has exceptions (and so unwinding), however Rust frames are never unwound, and so there's no need for the personality function.
Zoxc commentedon Sep 19, 2017
I would like the
Locationinterface to both support the ability to pass backtraces (effectively afn caller(&self) -> Option<Location>) and decompression of location information which requires accessing this information in a closure passed to aLocationfunction to avoid heap allocation.Zoxc commentedon Sep 19, 2017
We should also support no location information at all, and abstract location information (for example just an identifying number which can be used to find the relevant information in some external source).
Zoxc commentedon Sep 19, 2017
I did not notice that
PanicInfoandLocationwere already stable. I guess we can just deprecatePanicInfo::locationand make it returnNoneif we want some more expressive API in the future.Zoxc commentedon Sep 19, 2017
I'm really not a fan of using the same API for payloads and messages. I'd rather
panic!be pure message and provide some other API for payloads. So basically I wantPanicInfowithoutlocationandpayload. I have not seen any motivation for payloads for no_std use cases either.Zoxc commentedon Sep 21, 2017
I kind of prefer a
PanicInfotype with no fields or methods and just anDisplayimplementation.One problem with mixing the payload and the message is that we can't strip panic messages from the binary without changing the meaning of programs relying on payloads.
SimonSapin commentedon Jan 23, 2018
#47687 does part of the implementation. I think after that what’s needed is:
panic_fmtlang item from(msg: fmt::Arguments, file: &'static str, line: u32, col: u32) -> !to(&PanicInfo) -> !. This a breaking change to an unstable feature. (Maybe also rename it tobegin_panicor something withoutfmtin the name?)PanicInfoinsrc/libcore/panicking.rsto call the modified lang item, use the&'static strmessage as the payload inpanic()and a value of a new privatestruct NoPayload;type inpanic_fmt()core::panicking::panicfunction generic to accept anyP: Any + Sendpayload instead of just&'static str.#[panic_implementation]proc-macro attribute gated on#![feature(panic_implementation)]that checks that it is on aextern fnwith the appropriate signature, and expands to#[lang = "panic_fmt"]. This expansion uses stability hygiene such that the containing crate does not need thelang_itemsfeature gate, only thepanic_implementationone (until that one is stabilized)error[E0152]: duplicate lang item found: `panic_fmt`error to have its own error number and a message that talks about duplicate#[panic_implementation]instead. Or maybe write new code to emit that new error when appropriate. See what the implementation of#[global_allocator]does.Note however that
src/libcore/panicking.rscontains some comments about doing a things a certain way so that so that the linker can eliminate some of the string formatting machinery to limit code size bloat when formatting is not otherwise used. It’s possible that these changes would defeat those optimizations. I don’t know what we can do to try and preserve them while implementing RFC 2070.CC @japaric
SimonSapin commentedon Jan 27, 2018
@Zoxc We can still propose changing RFC 2070, but a
Box<Any + Send + 'static>payload for panics is already part of some stable APIs:std::thread::Result, the return type ofstd::thread::JoinHandleandstd::panic::catch_unwindstd::panic::resume_unwindPanicInfo::payloadandstd::panic::set_hookare already stableZoxc commentedon Jan 27, 2018
@SimonSapin We could just pass a
NoPayloadstruct for panics without payloads though. Anyway we don't need to repeat mistakes in libcore.82 remaining items
Remove stabilized features (#25)
sanmai-NL commentedon Oct 19, 2018
@Centril: Can you please update the OP with the current status (stabilization etc.)?
Centril commentedon Oct 19, 2018
@sanmai-NL I will defer this to @japaric since they are most up to date as to the status.
sanmai-NL commentedon Oct 19, 2018
@Centril: I saw at the end of this thread a very clear status indication, so I considered it a management thing requiring no involvement in the effort.
Centril commentedon Oct 19, 2018
@sanmai-NL ok, I ticked some boxes which seemed fulfilled; but I don't have the time to do a more in-depth review right now. :)
Remove stabilized features (#25)
Remove stabilized features (rust-osdev#25)
andreeaflorescu commentedon Jan 11, 2019
Hey, I got to this issue because it is linked to the
messagemethod ofPanicInfowhich is currently available only in rust nightly according to the the docs. As this issue is closed I was wondering if there's any plan to move the message method to stable.Related to the following issues in Firecracker:
Is there another recommended way to get the panic information? I was also thinking about replacing the panic_hook with catch_unwind but we might get into problems if the external crates that we are using are implementing panic with abort.
curiousleo commentedon Nov 15, 2019
@bors I think this issue should be re-opened until
panic_info_messageis no longer an unstable feature. Currently it still is:rust/src/libcore/panic.rs
Line 93 in 0f12bad
yodaldevoid commentedon Nov 15, 2019
@Centril @japaric about the the above message as @bors is a bot.
curiousleo commentedon Nov 15, 2019
Lol thanks!
eddyb commentedon Nov 15, 2019
It's not even the bot (@bors) closing the issue, this is a GitHub feature.
When a PR with the right keywords in its description (#51366 in this case) gets merged, issues can be closed automatically by GitHub.
@curiousleo I think the problem there is the unstable feature
panic_info_messagedidn't get its own tracking issue, but I'm not sure.Also a bit surprised that @andreeaflorescu didn't get a reply in almost a year...
Fix the tracking issue number for `PanicInfo::message`
SimonSapin commentedon Nov 26, 2019
#66771 changes the tracking issue of
PanicInfo::messageto #66745, which also has some discussion of what to do about it.curiousleo commentedon Nov 26, 2019
Thanks for following up! That's massively appreciated. I'll keep an eye on those two issues.