Closed SimonSapin closed 2 months ago
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.
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
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.
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.)
@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 https://github.com/rust-lang/rust/issues/66740#issuecomment-558223913
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
.
I thought the point of the message field was that core can't make a payload since it can't allocate?
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.
@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 :)
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.
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.
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
@SimonSapin proposal cancelled.
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. ;)
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.
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:
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.
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?
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?
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.
We discussed this in the libs-api meeting today. We concluded that before stabilizing this, we need to make sure it works (doesn't return None
) for std::panic!() as well. That is already the case with Rust 2021's std::panic!() (since it's identical to core::panic!() in this edition), but not for Rust 2015/2018's std::panic!().
Once that is fixed, we feel okay with returning a placeholder message for non-string panics (panics from panic_any
or Rust 2015/2018's panic!(not_a_string)
), at which point the function can return an Arguments
unconditionally, rather than an Option
.
(And also, Arguments
should be returned by value, not by reference.)
Any progress on stabilization?
It would great to have this little feature.
Still nothing? What's missing?
@m-ou-se can this be stabilized after blocker was resolved in the pull request #115974?
@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.)
Can it return impl Display
or so?
I would vote for an opaque PanicMessage
type that would also implement Display
.
Did that in this PR: https://github.com/rust-lang/rust/pull/126330
@rfcbot merge
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.
:bell: This is now entering its final comment period, as per the review above. :bell:
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.
https://github.com/rust-lang/rust/issues/44489 was closed when https://github.com/rust-lang/rust/pull/51366 stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature:
History:
Unresolved questions:
fmt::Arguments
or an opaquePanicMessage
? The first is simpler, but the latter allows a bit more flexibility for future changes.