ICE abort due to nested panic while panic-unwinding inside a proc-macro

[Veetaha]

I tried this code:

// lib.rs
#[derive(from_variants::FromVariants)]
pub(crate) enum FooBarity {
    Bar(bool, u8),
}

A ready-made repository with the reproduction is here.

The version of from_variants crate is 1.0.0.

I expected to see this happen:

This is not the intended usage of FromVariants proc macro. It expects an enum with tuple-style variants of a single arity. Best would be if FromVariants reported this as a pretty compile error with proper spans, but even if the implementation of proc macro fails to do that, then rustc shouldn't abort on a double-panic. The compiler should report that there is an error in exactly "this proc macro" and the output of the proc macro was "this".

Instead, this happened:
Rustc aborted, and the following output was seen in the terminal:

cargo check
   Compiling proc-macro2 v1.0.49
   Compiling quote v1.0.23
   Compiling unicode-ident v1.0.6
   Compiling syn v1.0.107
   Compiling ident_case v1.0.1
   Compiling fnv v1.0.7
   Compiling strsim v0.10.0
   Compiling darling_core v0.13.4
   Compiling darling_macro v0.13.4
   Compiling darling v0.13.4
   Compiling from_variants_impl v1.0.0
    Checking from_variants v1.0.0
    Checking rustc-ice-double-panic-reproduction v0.1.0 (/home/veetaha/dev/rustc-ice-double-panic-reproduction)
thread panicked while panicking. aborting.
error: could not compile `rustc-ice-double-panic-reproduction`

Caused by:
  process didn't exit successfully: `rustc --crate-name rustc_ice_double_panic_reproduction --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 -C metadata=59bd2ae5acf02373 -C extra-filename=-59bd2ae5acf02373 --out-dir /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps -C incremental=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/incremental -L dependency=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps --extern from_variants=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants-efa1e139161f23f5.rmeta` (signal: 6, SIGABRT: process abort signal)

Meta

The problem does reproduce both on stable and nightly versions of rustc and cargo:

Stable:

• cargo 1.66.0 (d65d197ad 2022-11-15)
• rustc 1.66.0 (69f9c33d7 2022-12-12)

Nightly:

• rustc 1.66.0 (69f9c33d7 2022-12-12)
• rustc 1.68.0-nightly (ad8ae0504 2022-12-29)

Unfortunately, RUST_BACTRACE=1 doesn't seem to produce a stack trace. I suppose it's because this is an abort.

But here is a snippet of the log of running RUSTC_LOG=trace cargo +nightly check:

Stripped version of the log that "might" be of interest

INFO rustc_metadata::creader resolving dep crate from_variants_impl hash: `1e48d5fccc90ee71` extra filename: `-51d45b4cefdd50d8`
INFO rustc_metadata::creader resolving crate `from_variants_impl`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator lib candidate: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-51d45b4cefdd50d8.so
INFO rustc_metadata::locator dylib reading metadata from: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-51d45b4cefdd50d8.so
INFO rustc_metadata::locator Rejecting via proc macro: expected false got true
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::locator lib candidate: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-51d45b4cefdd50d8.so
INFO rustc_metadata::locator lib candidate: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-cd9b885ca1b6ee81.so
INFO rustc_metadata::locator dylib reading metadata from: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-cd9b885ca1b6ee81.so
INFO rustc_metadata::locator Rejecting via version: expected rustc 1.68.0-nightly (ad8ae0504 2022-12-29) got rustc 1.66.0 (69f9c33d7 2022-12-12)
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::locator lib candidate: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-51d45b4cefdd50d8.so
INFO rustc_metadata::locator dylib reading metadata from: /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants_impl-51d45b4cefdd50d8.so
INFO rustc_metadata::creader register crate `from_variants_impl` (cnum = 21. private_dep = false)
INFO rustc_metadata::creader resolving crate `from_variants`
thread panicked while panicking. aborting.
error: could not compile `rustc-ice-double-panic-reproduction`

Caused by:
  process didn't exit successfully: `rustc --crate-name rustc_ice_double_panic_reproduction --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=151 --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 -C metadata=4365a24095010a27 -C extra-filename=-4365a24095010a27 --out-dir /home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps -C incremental=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/incremental -L dependency=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps --extern from_variants=/home/veetaha/dev/rustc-ice-double-panic-reproduction/target/debug/deps/libfrom_variants-f46dfc5abe2fbb3e.rmeta` (signal: 6, SIGABRT: process abort signal)

But here is the full log anyway:

rustc-trace-full.log

[Veetaha]

cc @TedDriggs (the author of from_variants, just for your information)

[pnkfelix]

Note: Since the from_variants crate has been since updated, the problem described here does not duplicate via the steps described unless you use the Cargo.lock file that is part of the linked repository.

---

In any case, I have narrowed the problem down to a simple MCVE, which one can observe by putting the following files into the appropriate locations in the test/ui/ directory:

File: test/ui/proc-macro/issue-106298-double-panic-in-proc-macro.rs

// aux-build:double-panic-during-expand.rs

#[macro_use]
extern crate double_panic_during_expand;

#[derive(double_panic_during_expand::Panic)]
struct S { x: u8 }

fn main() { }

File: test/ui/proc-macro/auxilliary/double-panic-during-expand.rs

// force-host
// no-prefer-dynamic
#![crate_type = "proc-macro"]
extern crate proc_macro;
struct PanicOnDrop;

impl Drop for PanicOnDrop {
    fn drop(&mut self) { panic!("panic on drop!"); }
}

#[proc_macro_derive(Panic)]
pub fn derive(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
    let _p_on_d = PanicOnDrop;
    panic!("panic during panic-during-expand's derive")
}

With the above files in place, for me running x.py test --stage 1 tests/ui/proc-macro yields:

failures:

---- [ui] rust.git/tests/ui/proc-macro/issue-106298-double-panic-in-proc-macro.rs stdout ----

error: Error: expected failure status (Some(1)) but received status None.
status: signal: 6 (SIGABRT) (core dumped)
command: <snip>
stdout: none
--- stderr -------------------------------
thread panicked while panicking. aborting.
------------------------------------------



failures:
    [ui] rust.git/tests/ui/proc-macro/issue-106298-double-panic-in-proc-macro.rs

[pnkfelix]

@rustbot label: -E-needs-mcve

[pnkfelix]

Today, if you pass -Z proc-macro-backtrace during the final rustc invocation, you at least get a stack trace dump for the first panic that occurs (before unwinding starts), i.e. the panic!("panic during panic-during-expand's derive") in my example above.

We may want to consider turning on the top level panic output, without the stack trace, unconditionally, in order to improve the user experience here when one encounters an abort due to a nested panic during the unwinding of the macro.

[pnkfelix]

Given that we already abort on double-panic, the main alternative I can see to turning on top-level panic output unconditionally is to allow code more ability to customize the message that's printed when we do abort due to a double-panic.

It can't be anything too sophisticated, because at the point where we're responding to a double-panic, we're already assuming we cannot allocate etc.

But just being able to override (temporarily) the message with a different &'static str, e.g.: "panicked during unwinding from macro expansion" or something along those lines, would be better here than the current flat "thread panicked while panicking. aborting." that supplies no contextual information at all about where the problem arose.