Split core's PanicInfo and std's PanicInfo

[m-ou-se]

PanicInfo is used in two ways:

1. As argument to the #[panic_handler] in no_std context.
2. As argument to the panic hook 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 #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):

rust/library/core/src/panic/panic_info.rs

Lines 171 to 172 in 0692db1

	// NOTE: we cannot use downcast_ref::<String>() here
	// since String is not available in core!

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: #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 in std context (where panics can have an arbitrary payload), while core::panic::PanicInfo is the argument to the #[panic_handler] 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().

[RalfJung]

I like this idea. :) I think it is somewhat similar to my musings from a few years ago, but goes a lot further: instead of just making these two cases the two variants of an enum, they become two entirely separate types. This means the parts they share have to be duplicated, but being able to have one of them in std does seem extremely useful.

[craterbot]

🎉 Experiment pr-115974 is completed!
📊 44 regressed and 3 fixed (370213 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[m-ou-se]

Crater results:

15 failures are because of usage of the unstable .message() method (which changed signature). All of these crates explicitly opted out of stability using a nightly feature flag to use this unstable method.

Of those 15, two additionally also use .payload() on core::panic::PanicInfo, which no longer exists (in core) after this PR. I will add a #[deprecated] fn payload to core's PanicInfo that returns a dummy value (identical in behavior to before this PR) to address that. (But these two crates would need changes anyway because of their unstable usage of .message().)

20 crates that failed to build because a dependency cannot be built.

7 unrelated failures (disk full, etc.).

And 2 regressions of stable code:

• yacurses 0.2.4 imports PanicInfo from core rather than std, even though it is only used with a panic handler for std::panic::set_hook: https://github.com/Lokathor/yacurses/blob/8d6230a428f521f6de33a508e922c6da7aa8be6f/src/lib.rs#L52 (cc @Lokathor)
• damip/rswasm (only on GitHub, not on crates.io) uses core::panic::PanicInfo in the panic hook signature, which is also only used with std::panic::set_hook: https://github.com/damip/rswasm/blob/5c58c9e079e5bdc3fef611072410ca4f4e6d99eb/src/lib.rs#L55 (cc @damip) (edit: fixed!)

Neither of these two are cases where a panic handler/hook is a function that is used both as a no_std #[panic_handler] and as a std panic hook. In both cases, it is only used in combination with std::panic::set_hook, so they can be fixed by just changing core to std.

[m-ou-se]

Looks like we might actually be able to do this.

[RalfJung]

Can't this use info.payload_as_str()?

[m-ou-se]

I want to use the same fallback string ("Box<dyn Any>") as in the other cases here, so I re-use the same helper function here. And that helper function doesn't use PanicHookInfo::payload_as_str(), because it is also used in places where there is no PanicHookInfo.

[RalfJung]

Makes sense... looking at my own code doing these downcasts, it's mostly working on the return value from catch_unwind, where there's also no PanicHookInfo. Maybe we should have some more widely used helper method that works on all Box<dyn Any + ...> or &dyn Any or so.

[m-ou-se]

@RalfJung Thanks for catching those things! I've addressed your comments in #126322

[Manishearth]

This caused a minor regression in nightly: #126766