run non-const Display/Debug impls for const panic message

[oli-obk]

Given that the CTFE core engine already supports the entire display machinery (demonstrated by the fact that it works in Miri), we might alternatively poke a small hole into the const checks that allows executing formatting machinery from panic_fmt only -- something like "miri unleashed", but more targeted.

Originally posted by @RalfJung in #78356 (comment)

Basically the same rationale as allowing -> _ return types in the parser, to get a better error later. In this case, when you use panic!() in CTFE, you are going to fail the build anyway, so we can just as well run something that may fail to get evaluated because it does something horribly unconst.

The only problem is that then const fn can execute non-const code at runtime during the panic machinery and before actually panicking, which may not be desirable.

[RalfJung]

My thinking was that we'd still have some heavy checks on the code format_args! expands to inside const fn to ensure that it does not run user-defined Display/Debug -- basically, we can just have a list of types that are permitted here, and reject the rest.
So, Arguments::new_v1 would only be allowed under some very special conditions inside const fn.

(This can theoretically be side-stepped with transmute, but whoever does that really can't expect any kind of guarantees^^.)

[Aaron1011]

In this case, when you use panic!() in CTFE, you are going to fail the build anyway, so we can just as well run something that may fail to get evaluated because it does something horribly unconst.

This is only true because we don't currently support const catch_unwind (and const unwinding is only implemented in Miri, not the CTFE). If we ever decided to support const catch_unwind, then we would need to make catching an 'unconst panic' into a hard error.

[oli-obk]

True, but I personally believe we should never support that. It's not really something that is useful in CTFE. Catching panics is solely there to prevent running across FFI boundaries or to create somewhat isolated units like threads or e.g. tabs or tasks in applications. CTFE is already perfectly isolated, and since there is no unwinding, there's no problem with FFI boundaries either. There's also no resources that need to be freed, as the entire evaluator is freed after every (successful or not) evaluation, including the entire virtual memory (modulo some things like vtables).

[oli-obk]

Almost finished impl that can probably be revived: #90488

[RalfJung]

Note however that it will need some adjustments because we don't want to run any user-defined formatting code, only the code in std.