Tracking issue for PanicInfo::message

[SimonSapin]

#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.

[SimonSapin]

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.

[rfcbot]

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

• @Amanieu
• @Kimundi
• @KodrAus
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• single-arg core::panic (Tracking issue for PanicInfo::message #66745 (comment))

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.

[SimonSapin]

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]

@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]

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

[SimonSapin]

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]

@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]

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.