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.

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

[alexcrichton]

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]

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]

@SimonSapin proposal cancelled.

[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 :)

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]

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]

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.

[m-ou-se]

Did that in this PR: #126330

[m-ou-se]

@rfcbot merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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]

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

[rfcbot]

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.