Rust: Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications

[aturon]

Update(2018-08-28)

• Stabilization summary.
• FCP checkboxes

---

This is a tracking issue for the RFC "stable mechanism to specify the behavior of panic! in no-std applications " (rust-lang/rfcs#2070).

Steps:

• [x] Implement the RFC
• [x] Adjust documentation (see instructions on forge)
  
  
  
  • [ ] The doc-comment of libcore mentions rust_begin_panic
  
  
• [x] Stabilization PR (see instructions on forge)

Unresolved questions:

fmt::Display

Should the Display of PanicInfo format the panic information as "panicked at 'reason', src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as
"reason".

Unwinding in no-std

Is this design compatible, or can it be extended to work, with unwinding
implementations for no-std environments?

Issues to solve before stabilization

• [x] panic_implementation: Error message still talks about the panic_fmt lang item when missing #51341
• [x] panic_implementation: no_mangle attribute needed? #51342
• [x] rust_begin_unwind not emitted when crate-type = bin #51671

[whitequark]

Unwinding in no-std

Is this design compatible, or can it be extended to work, with unwinding
implementations for no-std environments?

As someone with a working unwinding implementation in a no_std environment (not with a Rust personality function though), I can answer this if someone summarizes the feature for me. I kind of lost track and I don't have time to get into every minor detail at the moment.

[yodaldevoid]

As someone with a working unwinding implementation in a no_std environment (not with a Rust personality function though)...

Sorry to bring this off topic so soon, but could you explain this? I was under the impression that unless you wanted to implement unwinding in an ad-hoc way (e.g. doing unwinding during panic by explicitly calling some function) you had to implement the eh_personality function.

[whitequark]

I was under the impression that unless you wanted to implement unwinding in an ad-hoc way (e.g. doing unwinding during panic by explicitly calling some function) you had to implement the eh_personality function.

I use unwinding in a language runtime. The language has exceptions (and so unwinding), however Rust frames are never unwound, and so there's no need for the personality function.

[Zoxc]

I would like the Location interface to both support the ability to pass backtraces (effectively a fn caller(&self) -> Option<Location>) and decompression of location information which requires accessing this information in a closure passed to a Location function to avoid heap allocation.

[Zoxc]

We should also support no location information at all, and abstract location information (for example just an identifying number which can be used to find the relevant information in some external source).

[Zoxc]

I did not notice that PanicInfo and Location were already stable. I guess we can just deprecate PanicInfo::location and make it return None if we want some more expressive API in the future.

[Zoxc]

I'm really not a fan of using the same API for payloads and messages. I'd rather panic! be pure message and provide some other API for payloads. So basically I want PanicInfo without location and payload. I have not seen any motivation for payloads for no_std use cases either.

[Zoxc]

I kind of prefer a PanicInfo type with no fields or methods and just an Display implementation.

One problem with mixing the payload and the message is that we can't strip panic messages from the binary without changing the meaning of programs relying on payloads.

[SimonSapin]

47687 does part of the implementation. I think after that what’s needed is:

• Change the signature of the panic_fmt lang item from (msg: fmt::Arguments, file: &'static str, line: u32, col: u32) -> ! to (&PanicInfo) -> !. This a breaking change to an unstable feature. (Maybe also rename it to begin_panic or something without fmt in the name?)
  
  
  
  • When creating a PanicInfo in src/libcore/panicking.rs to call the modified lang item, use the &'static str message as the payload in panic() and a value of a new private struct NoPayload; type in panic_fmt()
  
  
  • Make that core::panicking::panic function generic to accept any P: Any + Send payload instead of just &'static str.
  
  
• Add an unstable #[panic_implementation] proc-macro attribute gated on #![feature(panic_implementation)] that checks that it is on a extern fn with the appropriate signature, and expands to #[lang = "panic_fmt"]. This expansion uses stability hygiene such that the containing crate does not need the lang_items feature gate, only the panic_implementation one (until that one is stabilized)
• Change the error[E0152]: duplicate lang item found: `panic_fmt` error to have its own error number and a message that talks about duplicate #[panic_implementation] instead. Or maybe write new code to emit that new error when appropriate. See what the implementation of #[global_allocator] does.

Note however that src/libcore/panicking.rs contains some comments about doing a things a certain way so that so that the linker can eliminate some of the string formatting machinery to limit code size bloat when formatting is not otherwise used. It’s possible that these changes would defeat those optimizations. I don’t know what we can do to try and preserve them while implementing RFC 2070.

CC @japaric

[SimonSapin]

@Zoxc We can still propose changing RFC 2070, but a Box<Any + Send + 'static> payload for panics is already part of some stable APIs:

• In std::thread::Result, the return type of std::thread::JoinHandle and std::panic::catch_unwind
• As a parameter of std::panic::resume_unwind
• PanicInfo::payload and std::panic::set_hook are already stable

[Zoxc]

@SimonSapin We could just pass a NoPayload struct for panics without payloads though. Anyway we don't need to repeat mistakes in libcore.

[nagisa]

From what I can tell, the RFC still does not address removal of unnecessary panic information directly, however it is an extremely easy thing to do that does not require much extra design past what was already accepted.

Consider for example this scenario:

#[panic_implementation]
fn my_panic_impl(pi: &PanicInfo) -> ! {
    abort()
}

This is a case, where it is entirely within the power of compiler to not keep any strings, line numbers, etc. pertaining to panic locations. However as soon as the panic implementation uses any information:

#[panic_implementation]
fn my_panic_impl(pi: &PanicInfo) -> ! {
    abort_with_line(pi.location(),map(|l| l.line()));
}
````

the compiler is forced to keep *all* the panic information, despite the fact that only the line numbers are of any interest for that particular implementation of panicking.

---

I want to propose a following change (benefits of which are laid out at the end of this comment):

```rust
struct AnyConcreteTypeMayGoHere { line: Option<u64> }

impl ::core::panic::PanicInfoCtr for AnyConcreteTypeMayGoHere {
    const fn new_v1(message: Option<&fmt::Arguments>, location: Option<Location>, ...etc) -> Self {
        AnyConcreteTypeMayGoHere { line: location.map(|l| l.line()) }
    }
}

#[panic_implementation]
fn my_panic_impl(pi: &AnyConcreteTypeMayGoHere) -> ! { abort_with_line(pi.line) }

and at the location of panic rust would generate code similar to this (with _ filled in with the type that my_panic_impl takes as an argument):

static PANIC_INFO: _ = <_ as ::core::panic::PanicInfoCtr>::new_v1(args, loc, ...);
my_panic_impl(&PANIC_INFO);

Benefits of this approach are:

1. It allows users to only keep the important bits about the panic, without relying on the compiler optimisations. AnyConcreteTypeMayGoHere will only retain line info even before optimisations come into play. It would also allow omitting the panic information entirely (important not only for embedded and wasm, but also closed-source code that doesn't want to expose internal information¹)
2. It is fairly extensible in backward-compatible manner without breaking the users. Consider for example addition of column numbers, which bloated various applications where code size is very important. With AnyConcreteTypeMayGoHere not retaining the column number in the first place, no extra bloat would’ve been introduced. Furthermore, if we wanted to add another argument to the PanicInfo constructor, new_v2(...) with default implementation calling new_v1 would be a backward-compatible change, etc etc.

libpanic_unwind/libpanic_abort would then provide their own #[panic_implementation] that takes &std::panic::PanicInfo as an argument, and libcore would provide a few default common-sense implementations of PanicInfoCtr trait -- one that mimics the std::panic::PanicInfo as closely as feasible, one that retains no information whatsoever, etc, so that #[panic_implementation] could be made stable before const fn is. And people whom none of defaults work out can implement their own PanicInfo using the const_fn unstable feature.

¹: there were a few issues about this, but I can’t find them anymore.

[nagisa]

Status update: I realised above cannot work without being very unwieldy. Namely, the proposal above would require the panic_implementation to be available to all the leaf crates, before code for them could be generated. This, unlike e.g. custom allocator providers, wouldn’t be something that would work simply by linking in some stuff from anywhere in the crate graph.

[glandium]

There is an issue that IMHO, a stable mechanism for panic! in no-std applications should take into account: for at least two reasons, you can only set the panic handler in leaf crates.

One of them is issue #48661, where the linker simply removes the panic handler if it's in its own crate.

The second of them is that the cargo test harness pulls std, and the build fails with:

error: duplicate lang item in crate `std`: `panic_fmt`.
  |
  = note: first defined in crate `panic`.

and there is no way for such a crate to be built differently for test.

[japaric]

@glandium

The second of them is that the cargo test harness pulls std, and the build fails with:

This may be a problem short term but custom test framework will become available this year and with those it will be possible to write test runners than don't rely on unwinding (e.g. unit tests return Err to indicate failure) which will make it possible to test targets (e.g. thumbv7m-none-eabi) that don't have a panic implementation that unwinds.

@nagisa

Namely, the proposal above would require the panic_implementation to be available to all the leaf crates, before code for them could be generated.

This is probably a bad idea but would it be possible to store all panic!s in MIR format and defer the actual generation of the static variable (and the llvm-ir) until the user defined PanicInfo struct is known?

[nagisa]

Yeah, without overthinking the idea too much, I think that would be possible, however it has a hard prerequisite on MIR-only (r)libs.

[glandium]

@japaric: there are other reasons than unwinding to want to use std for tests on otherwise no_std crates. If your panic function is in a crate that contains nothing else, maybe a #[cfg(not(test))] on the extern crate can save you, but if your panic function is in a crate along with other things, there's no way out.

[nagisa]

A summary from the All Hands /wrt panic size problem.

We did discuss various approaches to handling the issue of panic size, and figured out that we’d love to have something that works in all scenarios such as non-lto builds and even debug builds. We didn’t arrive at any particular design, but we managed to reject a number of designs that wouldn’t work and also realised that the only real way to properly implement any design would rely on MIR-only rlibs.

With that in mind, this design seems to be as good as any other and, as long as we stabilise #[panic_implementation] carefully (i.e. the signature and behaviour, but not the exact expansion), we should be in a good place to implement a solution for panic sizes as well.

---

I’m willing to mentor implementation of the RFC. The instructions written down by @SimonSapin are part-way right; I’ll write up some new and more detailed instructions over the week or two.

[csssuf]

I'd be interested in working on this, if nobody's already on it. I'll take a look at the partial instructions now and keep an eye out for the updated ones.

[nagisa]

Sorry for the long delay!

So to implement the RFC as it is proposed (past what’s already implemented in https://github.com/rust-lang/rust/pull/47687) the following need to be done:

• Add a new language items named panic_implementation and panic_info. Remove the panic_fmt language item. In this file. The signature of this new panic_implementation language item should be as such: fn panic_impl(&PanicInfo) -> !;.

  I still haven’t gotten around to implementing type checking for language items, so we’ll have to implement checking for the signature the same way as it is implemented for termination trait here (eww). Checks to be done here are:

  • Function does not terminate (its return is specified to be -> !;
  • Function has one argument only;
  • Function argument type is &PanicInfo, where PanicInfo is the panic_info language item.

• Annotate the PanicInfo with panic_info language item.

• Do not change the signature of libcore::panicking::panic, and instead add another function in the same file:

  extern {
       #[lang = "panic_implementation"]
       fn panic_impl(pi: &PanicInfo) -> !;
  }
  
  /// Constructs PanicInfo and calls the `panic_implementation`.
  fn panic_payload<M: Any + Send>(msg: M, file_line_col: &(&'static str, u32, u32)) -> ! {
      panic_impl(&...)
  }
  

  It is worth doing things this way, because the panic language item is something that is relied on by the compiler internals, and it would be a pain to adjust all those calls to call a changed language item.

  Then, adjust the macro_rules! panic 2nd matcher in src/libcore/macros.rs to call the new panic_payload function.

  Additionally, adjust panic and panic_fmt functions in a similar manner to call the
  panic_implementation language item as well. Both of these functions should construct PanicInfo
  with &NoPayload unit struct as the payload.

• Implement the #[panic_implementation] attribute. One of the approaches to the implementation
  would be to use proc-macros, but AFAICT this is a pretty big hammer to use for such a tiny
  staple. The expansion should end up being trivial, after all:

  #[panic_implementation]
  fn my_panic_implementation(pi: &PanicInfo) -> ! {
      // body
  }
  
  // expands to
  
  #[lang="panic_implementation"]
  fn my_panic_implementation(pi: &PanicInfo) -> ! {
      // body
  }
  

  so all that needs to be done to make this work is to adjust this visitor to also consider the panic_implementation attribute in addition to the lang attribute.

  This also makes reporting an error about duplicate panic_implementations as well as stability checking fairly easy. Adding a feature should happen here.

• Replace the implementation of lang = "panic_fmt" in libstd with the newly minted
  #[panic_implementation].

If you hit a roadblock or have any questions, you can find me (nagisa) and many more individuals who’d be willing to answer any questions on the #rustc IRC channel (irc.mozilla.org server).

[japaric]

PR #50338 implements #[panic_implementation] as per @nagisa instructions.

[japaric]

PR #50338 implements #[panic_implementation] as per @nagisa instructions.

PR landed yesterday and the feature is available in the latest nightly.

I have added issues #51341 and #51342 to this ticket description.

[pepyakin]

There is a regression which seems related to the panic_impl: https://github.com/rust-lang/rust/issues/51365

[SimonSapin]

The doc-comment of the core crate mentions a rust_begin_panic symbol and probably needs to be updated: https://doc.rust-lang.org/nightly/core/#how-to-use-the-core-library

(What about rust_eh_personality, is that still relevant?)

[nagisa]

@rfcbot fcp merge

This feature is one of the last few that we need(ed) to have #[no_std]/embedded be really feasible on stable versions of the compiler.

There are still implementation issues to solve before this can really be stabilised, however since these issues are "just" implementation bugs rather than inherent design flaws, they do not preclude running an FCP early.

Note, that for this feature we have punted on figuring out the issue of compiler retaining too much information about panics when a trivial #[panic_implementation] is used – implementing this essentially requires some sort of link-time codegen, which we aren’t getting before at least MIR-only-RLIBs.

[rfcbot]

Team member @nagisa has proposed to merge this. The next step is review by the rest of the tagged teams:

• [x] @Kimundi
• [x] @SimonSapin
• [x] @Zoxc
• [x] @alexcrichton
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @estebank
• [x] @michaelwoerister
• [x] @nagisa
• [x] @nikomatsakis
• [x] @oli-obk
• [x] @petrochenkov
• [ ] @pnkfelix
• [x] @sfackler
• [x] @varkor
• [x] @withoutboats

Concerns:

• attribute name resolved by https://github.com/rust-lang/rust/issues/44489#issuecomment-415140224
• panic_thin resolved by https://github.com/rust-lang/rust/issues/44489#issuecomment-410073560

Once a majority of reviewers approve (and none object), 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.

[nagisa]

What about rust_eh_personality, is that still relevant?

Yes, rust_eh_personality is important when you are trying to implement -Cpanic=unwind. -Cpanic=abort is the only thing that one can implement without extra unstable features.

[petrochenkov]

@rfcbot concern panic_thin

There's a competing RFC in flight - https://github.com/rust-lang/rfcs/pull/2305.
Supposedly there should be an explanation why the stabilized version is preferable and then https://github.com/rust-lang/rfcs/pull/2305 should be closed.

[SimonSapin]

The stated goal of that competing RFC is to avoid the code size cost of using core::fmt. However I think this is already possible with the current design:

#[panic_implementation]
fn panic(info: &core::panic::PanicInfo) -> ! {
    if let Some(s) = info.payload().downcast_ref::<&'static str>() {
        print(s)
    }
    loop {}
}

fn print(_s: &str) {
    // …
}

Creating a PanicInfo involves in many cases calling core::fmt::Arguments::new_v1, but that’s a trivial constructor with #[inline]. As far as I understand, the fmt machinery that takes a lot of code size would not be included as long as impl Dislay for PanicInfo is not used.

At the moment I think that this downcast to &str would return something with std::panic!("foo") but not core::panic!("foo"), that should be easy to fix.

[japaric]

re: Issues to solve before stabilization

51342 and #51671 have been fixed. #51341 has a fix in #51921.

[Ericson2314]

https://github.com/rust-lang/rfcs/pull/2492 is an alternative of using a trait and ZST, rather than annotation, for this. Should be orthogonal to https://github.com/rust-lang/rfcs/pull/2070 vs https://github.com/rust-lang/rfcs/pull/2305 I think.

[gnzlbg]

Solving https://github.com/rust-lang/rust/issues/51981 might require changing the signature of

fn panic_payload<M: Any + Send>(msg: M, files_lines_cols: &[(&'static str, u32, u32)]) -> ! {
    panic_impl(&...)
}

to take a slice. Although maybe PanicInfo allows us to solve this problem?

I'd like for any solution to this problem to allow us to provide better panic! error messages in the future.

[phil-opp]

Just as a heads up: The "panic_implementation: no_mangle attribute needed?" issue still persists. Seems like the fix wasn't successful. I mentioned it in the issue but got no reaction, so I thought I mention it here too because it's wrongly marked as solved in the issue description.

[Mark-Simulacrum]

The embedded working group would like this feature to be stabilized in time for the edition, so this is a ping to remind the folks who have not yet signed off on the FCP. It does look like there's at least some unresolved concerns as well, it would be good for someone knowledgeable in this area to champion this feature.

cc @Zoxc @cramertj @michaelwoerister @nikomatsakis @petrochenkov @pnkfelix @sfackler @varkor @withoutboats @japaric

[japaric]

@Mark-Simulacrum

The embedded working group would like this feature to be stabilized in time for the edition

Correction: We need this feature to be stabilized and part of the 2018 edition. Without it none of our examples / applications would compile on 1.31.

It does look like there's at least some unresolved concerns as well

@SimonSapin has addressed the panic_thin concern in https://github.com/rust-lang/rust/issues/44489#issuecomment-401418386.

---

@Centril has pointed out rust-lang/rfcs#2492 as an alternative to #![panic_implementation]. These are my thoughts on RFC 2492:

Unless there's 100% certainty that (a) we actually want to accept that RFC and that (b) we can implement it, test it and stabilize it by the 1.31-beta cutoff (2018-10-25) then I don't see it as a feasible alternative to #[panic_implementation]. Rejecting #[panic_implementation] in favor of RFC 2492 risks leaving support for embedded devices out of the edition release.

Even if we do accept RFC 2492 it's already too late for it to be only solution to the "needs / provides" problem. #[global_allocator], which RFC 2492 subsumes, is already in beta and will be in stable next week so both features will have to coexist and #[global_allocator] will have to be deprecated in favor of RFC 2492 when it becomes stable.

In conclusion: I don't see a decision on RFC 2492 as a blocker for stabilizing #[panic_implementation]. If we do accept RFC 2492, #[panic_implementation] will be in the same boat as #[global_allocator] and will eventually be deprecated.

I want to end my comment with this quote from the 2018 Roadmap:

Shipping requires the discipline to say “no” to exciting new ideas, and to say “yes” to delivering on ones we fear are flawed. We have to iterate toward perfection, providing useful snapshots along the way.

[Ericson2314]

That all makes sense to me. I don't think my RFC has loose design ends, but implementing and stabilizing anything at all in half a year I think is faster than the normal, right? It's nice with editions we have a clear route to depreciating language features. Ideally I would have written my RFC a year ago right after the explicit existential types RFC (can't even say why didn't) but oh well.

[Centril]

Makes sense to me as well; Nominating for next lang team meeting to make sure everyone there agree as well. :)

[SimonSapin]

@SimonSapin has addressed the panic_thin concern in https://github.com/rust-lang/rust/issues/44489#issuecomment-401418386.

Well, maybe. I haven’t actually checked that the core::fmt machinery’s code is indeed eliminated with such code. See for example https://github.com/rustwasm/team/issues/19#issuecomment-358814493

Beyond code size in terms of function bodies, I don’t know if the current API allows eliminating strings (either in the panic message/payload or in the location) when they end up not being used: https://github.com/rust-lang-nursery/embedded-wg/issues/41

[japaric]

Well, maybe. I haven’t actually checked that the core::fmt machinery’s code is indeed eliminated with such code.

From experience not using formatting at all in the panic handler and not using formatting elsewhere in your program (i.e. you must not use write! or print! like stuff that involves formatting) will indeed remove the core::fmt machinery. Your code in https://github.com/rust-lang/rust/issues/44489#issuecomment-401418386 would satisfy the first one of those two requirements.

I don’t know if the current API allows eliminating strings (either in the panic message/payload or in the location) when they end up not being used

The #[panic_implementation] API doesn't solve this problem. The panic_thin proposal doesn't solve it either. As mentioned in https://github.com/rust-lang/rust/issues/44489#issuecomment-378058031 solving the problem of payloads and panic information being kept in the binary requires pure MIR rlibs. I forget the exact details but the required changes won't affect the user interface of statically declaring the panic handler. That is the #[panic_implementation] API doesn't prevent us from fixing the size problem in the future.

[japaric]

#[panic_implementation] can be seen as a no_std, static version of std::panic::set_hook (stable API).

#[alloc_error_handler] (#51540) can be seen as a no_std, static version of std::alloc::set_alloc_error_hook (unstable API).

Would it be more consistent to rename #[panic_implementation] to #[panic_handler]?

Alternatively, the attributes could be renamed to #[*_hook] to match the name used in the std API, but the word hook, in programming, carries the meaning of something that alters / overrides the default behavior of a program so it doesn't seem appropriate.

cc @Centril @SimonSapin

[Centril]

@japaric I like #[panic_handler], it seems consistent, short and sweet. :)

[SimonSapin]

I would prefer to specifically not use the same term as in std API because they are different. The attributes (handlers?) are mandatory (in no_std apps using related functionality), set at compile-time, and statically dispatched. The hooks have a default, cannot be set until run-time, can be changed during run-time, and are dynamically dispatched

[SimonSapin]

solving the problem of payloads and panic information being kept in the binary requires pure MIR rlibs.

My reading of https://github.com/rust-lang/rust/issues/44489#issuecomment-378058031 is that MIR-only rlibs are required to eliminate unused data "in all scenarios such as non-lto builds and even debug builds". Wouldn’t (full) LTO achieve that result today?

the #[panic_implementation] API doesn't prevent us from fixing the size problem in the future.

I think some comments suggested that separate arguments would optimize better. If any field of PanicInfo is used through &PanicInfo, none of them can be optimized out.

[SimonSapin]

It was just pointed out to me that the attribute, since it is implemented as compiler code, can look at the function’s signature and eventually accept multiple signatures (possibly generating a wrapper function if needed). So we’re not necessarily stuck &PanicInfo forever, which solves my concern.

I’ve formally proposed FCP to postpone https://github.com/rust-lang/rfcs/pull/2305. @petrochenkov, I think this solves your concern.

I’ll file another one for https://github.com/rust-lang/rust/issues/44489#issuecomment-409392812 but it should be easy: let’s pick one of #[panic_implementation] or #[panic_handler]:

@rfcbot concern attribute name

[mark-i-m]

I will cast my vote for panic_handler

[petrochenkov]

@rfcbot resolve panic_thin

[Centril]

The lang team briefly discussed this and I think the general consensus was that the team does not want to block this on rust-lang/rfcs#2492.

[Centril]

@rfcbot poll libs compiler Can we find consensus around the name #[panic_handler]?

[SimonSapin]

I’ve added the attribute name to the agenda for tomorrow’s libs triage meeting.

[SimonSapin]

The libs team discussed this during today’s triage meeting. We’re happy with renaming to panic_handler, which is consistent with alloc_error_handler.

@rfcbot resolve attribute name

Anyone feels up to making a PR to rename? If that’s easy enough to implement, let’s also keep the old name for a while and make it emit a deprecation warning.

[SimonSapin]

Ping @Zoxc @michaelwoerister @nikomatsakis @pnkfelix @sfackler @withoutboats for your checkboxes in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881

[japaric]

Anyone feels up to making a PR to rename?

I'll make a PR.

[japaric]

I'll make a PR.

See #53619

[nikomatsakis]

@rfcbot fcp reviewed

I'm going to mark this as reviewed because it's been a while and I missed the initial FCP request (sorry about that), but for the record I'd generally prefer to see:

• a summary of the semantics to be stabilized
  
  
  
  • in particular any cases where things diverged from the RFC
    
    
    
    
    
    • it sounds like at minimum there has been some renaming
    
    
    
  
  
• links to test cases showing that we are testing those semantics
• a listing of bugs that remain to be fixed etc

I believe we also would like a commitment from the @rust-lang/docs team that there is enough information for them to be able to write docs on this feature (hopefully the RFC suffices here).

(We should formalize this process, though.)

[japaric]

As per Niko's request this is a summary of the above thread and covers what's
being stabilized, how it's tested, deviations from the RFC and remaining known
bugs:

RFC text: https://github.com/rust-lang/rfcs/blob/master/text/2070-panic-implementation.md

What's being stabilized:

• The panic_handler attribute. This attribute lets you define the behavior of
  core::panic!. This attribute is basically the old panic_fmt lang item but
  with a stable API.

What's not being stabilized at this point:

• Support for payloads in core::panic! (e.g. panic!(42)). This has not been
  implemented but it's backward compatible to add. Rationale was to speed up
  stabilization by not adding new functionality to core::panic!.

We test:

• That the panic_handler has the signature specified in the RFC:
  fn(&PanicInfo) -> !. Tests:

  • fn(PanicInfo) -> ()
  • fn(&'static PanicInfo) -> !
  • fn() -> !
  • fn<T>(&PanicInfo) -> !

• That only a single instance of panic_handler is allowed to exist in the
  crate dependency graph. Tests:

  • no_std context
  • collision with the panic_impl lang item (which is what panic_handler
    desugars to)
  • collision with the definition in std

• That the compiler rejects binary crates that do not define panic_handler.
  [Test]

• That the generated symbols have the right visibility. These are regressions
  tests for bugs that we encountered in practice. Tests:

  • WASM exports
  • WASM imports
  • panic_handler in top binary crate

Deviations from the RFC:

• The name of the attribute [was changed] from panic_implementation to panic_handler. Proposal

Remaining known bugs:

None left. There were a few bugs related to symbol visibility and codegen
options like LTO, but they have been fixed.

[rfcbot]

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

[Mark-Simulacrum]

Can @rust-lang/lang assign someone or update us on the current state here? Was this intended to be stabilized in RC? If so we need a stabilization PR ASAP.

[japaric]

@Mark-Simulacrum

Was this intended to be stabilized in RC?

Yes, it would be ideal to have this in RC1 (1.30-beta). If it doesn't make the beta cutoff, could we backport it?

If so we need a stabilization PR ASAP.

Stabilization PR

Reference PR

Updating / finishing them up right now.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[sanmai-NL]

@Centril: Can you please update the OP with the current status (stabilization etc.)?

[Centril]

@sanmai-NL I will defer this to @japaric since they are most up to date as to the status.

[sanmai-NL]

@Centril: I saw at the end of this thread a very clear status indication, so I considered it a management thing requiring no involvement in the effort.

[Centril]

@sanmai-NL ok, I ticked some boxes which seemed fulfilled; but I don't have the time to do a more in-depth review right now. :)

[andreeaflorescu]

Hey, I got to this issue because it is linked to the message method of PanicInfo which is currently available only in rust nightly according to the the docs. As this issue is closed I was wondering if there's any plan to move the message method to stable.
Related to the following issues in Firecracker:

• pretty-printing panics
• user inquiry

Is there another recommended way to get the panic information? I was also thinking about replacing the panic_hook with catch_unwind but we might get into problems if the external crates that we are using are implementing panic with abort.

[curiousleo]

@bors I think this issue should be re-opened until panic_info_message is no longer an unstable feature. Currently it still is: https://github.com/rust-lang/rust/blob/0f12bad718bb8b1fb2b1b7267a02fffaef6e1e3c/src/libcore/panic.rs#L93.

[yodaldevoid]

@Centril @japaric about the the above message as @bors is a bot.

[curiousleo]

@bors is a bot.

Lol thanks!

[eddyb]

It's not even the bot (@bors) closing the issue, this is a GitHub feature.
When a PR with the right keywords in its description (#51366 in this case) gets merged, issues can be closed automatically by GitHub.

@curiousleo I think the problem there is the unstable feature panic_info_message didn't get its own tracking issue, but I'm not sure.

Also a bit surprised that @andreeaflorescu didn't get a reply in almost a year...

[SimonSapin]

https://github.com/rust-lang/rust/pull/66771 changes the tracking issue of PanicInfo::message to https://github.com/rust-lang/rust/issues/66745, which also has some discussion of what to do about it.

[curiousleo]

66771 changes the tracking issue of PanicInfo::message to #66745, which also has some discussion of what to do about it.

Thanks for following up! That's massively appreciated. I'll keep an eye on those two issues.