Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for PanicInfo::message #66745

Open
SimonSapin opened this issue Nov 25, 2019 · 14 comments
Open

Tracking issue for PanicInfo::message #66745

SimonSapin opened this issue Nov 25, 2019 · 14 comments

Comments

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Nov 25, 2019

#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<'a> PanicInfo<'a> {
    /// If the `panic!` macro from the `core` crate (not from `std`)
    /// was used with a formatting string and some additional arguments,
    /// returns that message ready to be used for example with [`fmt::write`]
    ///
    /// [`fmt::write`]: ../fmt/fn.write.html
    #[unstable(feature = "panic_info_message", issue = "44489")]
    pub fn message(&self) -> Option<&fmt::Arguments<'_>> {
        self.message
    }
}

Edit: the core::panic module also still is unstable and links to #44489. (std::panic is stable however. It reexports the contents of core::panic and adds more.)

@SimonSapin

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

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

This comment has been minimized.

Copy link

@rfcbot rfcbot commented Nov 25, 2019

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.

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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

@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

This comment has been minimized.

Copy link
Member

@sfackler sfackler commented Nov 25, 2019

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

@SimonSapin

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

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

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton commented Nov 25, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 25, 2019

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

This comment has been minimized.

Copy link

@rfcbot rfcbot commented Nov 25, 2019

@SimonSapin proposal cancelled.

@RalfJung

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung commented Nov 26, 2019

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:

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

This comment has been minimized.

Copy link
Contributor Author

@SimonSapin SimonSapin commented Nov 26, 2019

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?

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

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung commented Nov 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.