Tracking issue for PanicInfo::message #66745

SimonSapin · 2019-11-25T15:13:01Z

#44489 was closed when #51366 stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature:

// In `core::panic`:

impl PanicInfo<'_> {
    /// The message that was given to the `panic!` macro.
    pub fn message(&self) -> PanicMessage<'_>;
}

// Opaque type that wraps a fmt::Arguments<'a>.
pub struct PanicMessage<'a> { .. }

impl Display for PanicMessage<'_>;
impl Debug for PanicMessage<'_>;

impl PanicMessage<'_> {
    pub fn as_str(&self) -> Option<&'static str>;
}

History:

Original tracking issue: Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications #44489
Discussion of payload vs message Tracking issue for PanicInfo::message #66745 (comment)
Making .message() infallible: Make PanicInfo::message infallible #115561
Split core/std PanicInfo into two types: Split core's PanicInfo and std's PanicInfo #115974
- This made core::panic::PanicInfo::message() infallible.
Use opaque return type: Return opaque type from PanicInfo::message() #126330
FCP
Stablization PR: Stabilize PanicInfo::message() and PanicMessage #126732

Unresolved questions:

Should it be infallible?
- Yes, by making std::panic::PanicHookInfo a different type.
What should the return type be?
- fmt::Arguments or an opaque PanicMessage? The first is simpler, but the latter allows a bit more flexibility for future changes.

The text was updated successfully, but these errors were encountered:

SimonSapin · 2019-11-25T15:17:59Z

Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method?

@rfcbot fcp merge

The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. core::panic! always creates a PanicInfo where message is Some, regardless of the number of arguments given. In the single-argument case, that argument is required to have type &str.

At first returning fmt::Arguments seemed unusual to me and I considered that we could make the method return Option<impl Display + 'a> instead, on the basis that calling its Display impl is almost the only useful thing to do with a Arguments. But Arguments has been stable and documented as the return type of format_args!(…) since 1.0.0, so maybe it’s fine.

SimonSapin · 2019-11-25T16:57:59Z

The core::panic module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. (std::panic is stable.)

SimonSapin · 2019-11-25T17:16:56Z

@rfcbot concern single-arg core::panic

Should we change libcore’s panic macro so that its single-argument form creates a PanicInfo with a payload instead of one with a message? CC #66740 (comment)

Pushing this idea further, it’s tempting to maybe remove PanicInfo::message entirely and instead have a payload whose dynamic type can be fmt::Arguments. But that doesn’t work because downcast_ref is a method of dyn Any + 'static and fmt::Arguments<'_> is not 'static.

sfackler · 2019-11-25T19:25:21Z

I thought the point of the message field was that core can't make a payload since it can't allocate?

SimonSapin · 2019-11-25T19:38:51Z

The struct is:

pub struct PanicInfo<'a> {
    payload: &'a (dyn Any + Send),
    message: Option<&'a fmt::Arguments<'a>>,
    location: &'a Location<'a>,
}

Both the payload and message fields involve borrowing. As far as PanicInfo is concerned, they could both be borrowing form a stack frame. (And as far as I understand they are, in practice today.)

It’s in the case of unwinding that there’s an owned Box<dyn Any + Send> that catch_unwind can return, which requires allocating.

SimonSapin · 2019-11-25T20:17:01Z

@RalfJung Based on the timing of https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html it looks like you may have thoughts on this :)

SimonSapin · 2019-11-25T20:31:57Z

Ah, https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html goes into how and why the panic handler in libstd (which is called by core::panic! if libstd is linked) ignores the payload it receives.

We could probably change this but it gets tricky: while most implementations of #[panic_handler] for no_std environments would be fine with receiving a borrowed payload, libstd wants to potentially take ownership and box it for unwinding.

alexcrichton · 2019-11-25T22:45:12Z

I have zero recollection for why this is the way it is, and I'm not really particularly interested in doing all the archaeology to dig up why it is the way it is. I'm not a huge fan of just stabilizing things because they happen to be there, but I don't really see why we wouldn't want to stabilize this. If there were a reason to not stabilize this though an investigation would presumably turn that up, but I'm not up to do that investigation myself.

SimonSapin · 2019-11-25T23:14:35Z

That’s totally fair.

I’m confident that this was more likely forgotten than deliberately left unstable. If deliberate we would have kept the tracking issue open or made a new one for the remaining bits. This is what lead me to propose stabilization.

Having dug a little more, and thanks to Ralf’s blog post, I think we may want at some point to revisit what data we expect PanicInfo to contain or not in various situation. In particular it could be interesting to extend core::panic!(foo) to support payloads other than &str and make it closer to std::panic!(foo).

Given those possibly-desirable changes, it may not be the time to add more constraints:

@rfcbot fcp cancel

rfcbot · 2019-11-25T23:14:36Z

@SimonSapin proposal cancelled.

RalfJung · 2019-11-26T10:10:16Z

Based on the timing of https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html it looks like you may have thoughts on this :)

Lol, I had no idea. ;)

Cleanup

So, indeed, I was wondering if we could do something about the duality of the message and payload fields in PanicInfo. I assume we cannot change the fact that the same type is used both of panic handlers and panic hooks.

Concretely, I was thinking of adjusting PanicInfo somewhat like this:

pub struct PanicInfo<'a> {
    payload: Payload<'a>,
    location: &'a Location<'a>,
}

enum Payload<'a> {
  Any(&'a (dyn Any + Send)),
  Message(&'a fmt::Arguments<'a>),
}

That would at least remove the need for the NoPayload hack in PanicInfo::internal_constructor. (The hack would likely move to PanicInfo::payload instead, but that is a smaller hack IMO: the hack is now not encoded in the state of PanicInfo any more, just in its dynamic API.)

I think this would retain all current functionality while clarifying the invariant of PanicInfo wrt. the payload (and explicitly calling the message a "payload"; right now it seems to be something that sits next to the payload which is inaccruate). But there are enough subtleties here that we'll only really know once someone implements this.

Extension: convenient convert-to-string

With this change, the panic hook would always get a Payload::Any. We should likely provide a method somewhere in libstd to factor out this code:

rust/src/libstd/panicking.rs

Lines 171 to 177 in 7d761fe

    
           let msg = match info.payload().downcast_ref::<&'static str>() { 
        
               Some(s) => *s, 
        
               None => match info.payload().downcast_ref::<String>() { 
        
                   Some(s) => &s[..], 
        
                   None => "Box<Any>", 
        
               } 
        
           };

I was imagining something like an extension trait on PanicInfo with a type like fn(&self) -> Option<&str>. However, the panic hook is not the only place where that conversion is useful; another situation is code that caught a panic and wants to extract the message. I expect most instances of that to just handle String payloads, not knowing that &str payloads are also common (that is certainly what happened when I wrote such code). So ideally we'd have a method that takes &(dyn Any+Send) and returns Option<&str>, but I do not have a good idea where to put that.

Extension: payload-carrying panics from libcore

This is the hard part, as we cannot use Box. I wonder if we can use a take-based approach, similar to BoxMeUp? Conceptually, core::panic!(payload) would put the panic into an Option<T>, and somehow pass an &mut Option<T> to the panic handler, and the implementation of said handler could then take the payload if it needs full ownership (like for unwinding). Except the panic handler cannot be generic, so it would have to be &mut Option<dyn Any+Send>, which is not a thing. But with enough unsafe code we could re-implement something that behaves like that.

I don't see any way to do this entirely safely; the panic handler that wants to take out the payload and put it somewhere needs to dynamically determine the size of the payload and arrange for there to be enough space. In liballoc, we could provide a safe wrapper for this that puts things into a Box<dyn Any+Send>, but in libcore, I don't think there is a safe API that we could provide to grab ownership. But maybe it is enough for the public API to expose ways to borrow the payload (should work for all non-unwinding handlers); if only libstd needs to take the payload (for unwinding) we could keep the unsafe part of the PanicInfo API internal.

Also, we certainly do not want a panic hook to take the payload out of its PanicInfo. At this point it seems to be quite a problem that panic hook and panic handler both use the same type. In fact, a panic handler likely wants a &mut PanicInfo<'_> to be able to take things without interior mutability. Is there any way we could make the #[panic_handler] attribute support both signatures, and then (based on the types of the PanicInfo methods) only &mut-based implementations will actually be able to get_mut or take the payload?

SimonSapin · 2019-11-26T10:37:35Z

We should likely provide a method somewhere in libstd to factor out this code:

I agree, but it’s can easily be an inherent method of PanicInfo nor of dyn Any+Send because those are in libcore which doesn’t have access to String. It feels slightly unfortunate that we’d need an extension trait just for this.

payload-carrying panics from libcore

I considered this yesterday and come to pretty much the same conclusions.

To take ownership of a payload of unknown size through a non-generic API we pretty much heap allocation, which for libcore means something like receiving an fn alloc(Layout) -> NonNull<()>, unsafely using ptr::write, and returning NonNull<dyn Any+Send> that is to be passed to Box::from_raw.

It’s not pretty, but if only libcore and libstd deal with this internally maybe that’s ok? Is there a use case for a #[panic_handler] other than libstd’s to take ownership of the payload?

RalfJung · 2019-11-26T12:14:28Z

I was thinking of a slightly different API actually:

fn get_payload_layout(&self) -> Layout;
unsafe fn take_payload(&mut self, ptr: *mut u8);

Here, take_payload does ptr.write to put the payload into caller-allocated storage; that storage must have (at least) size and align as given by get_payload_layout. What I did not consider is how to get out the vtable, so maybe that higher-order approach is better.

…=Amanieu Split core's PanicInfo and std's PanicInfo `PanicInfo` is used in two ways: 1. As argument to the `#[panic_handler]` in `no_std` context. 2. As argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in `std` context. In situation 1, the `PanicInfo` always has a *message* (of type `fmt::Arguments`), but never a *payload* (of type `&dyn Any`). In situation 2, the `PanicInfo` always has a *payload* (which is often a `String`), but not always a *message*. Having these as the same type is annoying. It means we can't add `.message()` to the first one without also finding a way to properly support it on the second one. (Which is what rust-lang#66745 is blocked on.) It also means that, because the implementation is in `core`, the implementation cannot make use of the `String` type (which doesn't exist in `core`): https://github.com/rust-lang/rust/blob/0692db1a9082380e027f354912229dfd6af37e78/library/core/src/panic/panic_info.rs#L171-L172 This also means that we cannot easily add a useful method like `PanicInfo::payload_as_str() -> Option<&str>` that works for both `&'static str` and `String` payloads. I don't see any good reasons for these to be the same type, other than historical reasons. --- This PR is makes 1 and 2 separate types. To try to avoid breaking existing code and reduce churn, the first one is still named `core::panic::PanicInfo`, and `std::panic::PanicInfo` is a new (deprecated) alias to `PanicHookInfo`. The crater run showed this as a viable option, since people write `core::` when defining a `#[panic_handler]` (because they're in `no_std`) and `std::` when writing a panic hook (since then they're definitely using `std`). On top of that, many definitions of a panic hook don't specify a type at all: they are written as a closure with an inferred argument type. (Based on some thoughts I was having here: rust-lang#115561 (comment)) --- For the release notes: > We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. > > `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. > > The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`.

Rollup merge of rust-lang#115974 - m-ou-se:panicinfo-and-panicinfo, r=Amanieu Split core's PanicInfo and std's PanicInfo `PanicInfo` is used in two ways: 1. As argument to the `#[panic_handler]` in `no_std` context. 2. As argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in `std` context. In situation 1, the `PanicInfo` always has a *message* (of type `fmt::Arguments`), but never a *payload* (of type `&dyn Any`). In situation 2, the `PanicInfo` always has a *payload* (which is often a `String`), but not always a *message*. Having these as the same type is annoying. It means we can't add `.message()` to the first one without also finding a way to properly support it on the second one. (Which is what rust-lang#66745 is blocked on.) It also means that, because the implementation is in `core`, the implementation cannot make use of the `String` type (which doesn't exist in `core`): https://github.com/rust-lang/rust/blob/0692db1a9082380e027f354912229dfd6af37e78/library/core/src/panic/panic_info.rs#L171-L172 This also means that we cannot easily add a useful method like `PanicInfo::payload_as_str() -> Option<&str>` that works for both `&'static str` and `String` payloads. I don't see any good reasons for these to be the same type, other than historical reasons. --- This PR is makes 1 and 2 separate types. To try to avoid breaking existing code and reduce churn, the first one is still named `core::panic::PanicInfo`, and `std::panic::PanicInfo` is a new (deprecated) alias to `PanicHookInfo`. The crater run showed this as a viable option, since people write `core::` when defining a `#[panic_handler]` (because they're in `no_std`) and `std::` when writing a panic hook (since then they're definitely using `std`). On top of that, many definitions of a panic hook don't specify a type at all: they are written as a closure with an inferred argument type. (Based on some thoughts I was having here: rust-lang#115561 (comment)) --- For the release notes: > We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. > > `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. > > The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`.

StackOverflowExcept1on · 2024-06-12T05:51:49Z

@m-ou-se can this be stabilized after blocker was resolved in the pull request #115974?

m-ou-se · 2024-06-12T11:38:59Z

@StackOverflowExcept1on Yes, soon, hopefully!

I've updated the overview at the top of this tracking issue.

The main question left before stabilization is the return type of the method. Should this return fmt::Arguments (as the unstable method does today), or should it return an opaque type PanicMessage that wraps that fmt::Arguments, so we can still change in the future? (In case we want to support different types of no_std panic, such as panicking with an Error or something.)

RalfJung · 2024-06-12T11:47:37Z

Can it return impl Display or so?

StackOverflowExcept1on · 2024-06-12T11:58:40Z

I would vote for an opaque PanicMessage type that would also implement Display.

m-ou-se · 2024-06-12T13:41:20Z

Did that in this PR: #126330

Return opaque type from PanicInfo::message() This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future. See rust-lang#66745

Return opaque type from PanicInfo::message() This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future. See rust-lang/rust#66745

m-ou-se · 2024-06-19T08:02:55Z

@rfcbot merge

rfcbot · 2024-06-19T08:02:57Z

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2024-06-19T12:15:23Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2024-06-29T12:30:41Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

Rollup merge of rust-lang#126732 - StackOverflowExcept1on:master, r=m-ou-se Stabilize `PanicInfo::message()` and `PanicMessage` Resolves rust-lang#66745 This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html). Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker): ```rust #![no_std] #![no_main] extern crate libc; #[no_mangle] extern "C" fn main() -> libc::c_int { panic!("I just panic every time"); } #[panic_handler] fn my_panic(panic_info: &core::panic::PanicInfo) -> ! { use arrayvec::ArrayString; use core::fmt::Write; let message = panic_info.message(); let location = panic_info.location().unwrap(); let mut debug_msg = ArrayString::<1024>::new(); let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'"); if debug_msg.try_push_str("\0").is_ok() { unsafe { libc::puts(debug_msg.as_ptr() as *const _); } } unsafe { libc::exit(libc::EXIT_FAILURE) } } ``` ``` $ cargo +stage1 run --release panicked with 'I just panic every time' at 'src/main.rs:8:5' ``` - [x] FCP: rust-lang#66745 (comment) r? libs-api

SimonSapin added B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 25, 2019

This comment was marked as outdated.

Sign in to view

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 25, 2019

SimonSapin changed the title ~~Tracking issue for PanicInfo::message~~ Tracking issue for PanicInfo::message and core::panic Nov 25, 2019

SimonSapin mentioned this issue Nov 25, 2019

Stabilize the #[alloc_error_handler] attribute (for no_std + liballoc) #66740

Closed

rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 25, 2019

SimonSapin changed the title ~~Tracking issue for PanicInfo::message and core::panic~~ Tracking issue for PanicInfo::message Nov 26, 2019

SimonSapin mentioned this issue Nov 26, 2019

Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications #44489

Closed

7 tasks

curiousleo mentioned this issue Dec 16, 2019

Where is the panic! log message ? rust-cli/human-panic#55

Open

RalfJung mentioned this issue Jan 2, 2020

libstd uses core::panic::Location where possible. #67137

Merged

daviddrysdale mentioned this issue Jan 17, 2020

Panic message not printed correctly project-oak/oak#483

Closed

mcy mentioned this issue Mar 3, 2020

Building Tock with stable rustc tock/tock#1654

Open

29 tasks

KodrAus added the Libs-Tracked Libs issues that are tracked on the team's project board. label Jul 30, 2020

m-ou-se mentioned this issue Jun 12, 2024

Return opaque type from PanicInfo::message() #126330

Merged

StackOverflowExcept1on mentioned this issue Jun 20, 2024

Stabilize PanicInfo::message() and PanicMessage #126732

Merged

1 task

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jun 29, 2024

rfcbot added the to-announce Announce this issue on triage meeting label Jun 29, 2024

bors closed this as completed in 61db24d Jul 1, 2024

apiraino removed the to-announce Announce this issue on triage meeting label Jul 4, 2024

Vickerinox mentioned this issue Aug 15, 2024

Adapted panic.rs to the newly stabilized message api SeleDreams/libnds-sys#3

Open

m-ou-se mentioned this issue Aug 15, 2024

regression: mismatched types (panic info hook stuff) #128890

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for PanicInfo::message #66745

Tracking issue for PanicInfo::message #66745

SimonSapin commented Nov 25, 2019 •

edited by m-ou-se

Loading

SimonSapin commented Nov 25, 2019

This comment was marked as outdated.

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

sfackler commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

alexcrichton commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

rfcbot commented Nov 25, 2019

RalfJung commented Nov 26, 2019

SimonSapin commented Nov 26, 2019

RalfJung commented Nov 26, 2019

StackOverflowExcept1on commented Jun 12, 2024

m-ou-se commented Jun 12, 2024

RalfJung commented Jun 12, 2024

StackOverflowExcept1on commented Jun 12, 2024

m-ou-se commented Jun 12, 2024

m-ou-se commented Jun 19, 2024

rfcbot commented Jun 19, 2024 •

edited by joshtriplett

Loading

rfcbot commented Jun 19, 2024

rfcbot commented Jun 29, 2024

Tracking issue for PanicInfo::message #66745

Tracking issue for PanicInfo::message #66745

Comments

SimonSapin commented Nov 25, 2019 • edited by m-ou-se Loading

SimonSapin commented Nov 25, 2019

This comment was marked as outdated.

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

sfackler commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

alexcrichton commented Nov 25, 2019

SimonSapin commented Nov 25, 2019

rfcbot commented Nov 25, 2019

RalfJung commented Nov 26, 2019

Cleanup

Extension: convenient convert-to-string

Extension: payload-carrying panics from libcore

SimonSapin commented Nov 26, 2019

RalfJung commented Nov 26, 2019

StackOverflowExcept1on commented Jun 12, 2024

m-ou-se commented Jun 12, 2024

RalfJung commented Jun 12, 2024

StackOverflowExcept1on commented Jun 12, 2024

m-ou-se commented Jun 12, 2024

m-ou-se commented Jun 19, 2024

rfcbot commented Jun 19, 2024 • edited by joshtriplett Loading

rfcbot commented Jun 19, 2024

rfcbot commented Jun 29, 2024

SimonSapin commented Nov 25, 2019 •

edited by m-ou-se

Loading

rfcbot commented Jun 19, 2024 •

edited by joshtriplett

Loading