ICE abort due to nested panic while panic-unwinding inside a proc-macro #106298
Comments
|
cc @TedDriggs (the author of |
JohnTitor
added
I-crash
|
Note: Since the 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 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 |
|
@rustbot label: -E-needs-mcve |
rustbot
removed
the
E-needs-mcve
pnkfelix
changed the title
|
Today, if you pass 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. |
|
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 |
- rust-lang/rust#99173 - rust-lang/rust#103708 - rust-lang/rust#104827 - rust-lang/rust#105209 - rust-lang/rust#106298 - rust-lang/rust#106423 Signed-off-by: Yuki Okushi <jtitor@2k36.org> rust-lang/rust#99173 Signed-off-by: Yuki Okushi <jtitor@2k36.org>
The rust/library/proc_macro/src/bridge/client.rs Line 385 in e08b379 The code that emits the aforementioned error message shown for double panics can be found here in the rust/library/std/src/panicking.rs Line 705 in e08b379 In order for the two separate programs to communicate, the panic hook either needs to be able to return something other than My point being it doesn't look simple :( |
I tried this code:
A ready-made repository with the reproduction is here.
The version of
from_variantscrate is1.0.0.I expected to see this happen:
This is not the intended usage of
FromVariantsproc macro. It expects an enum with tuple-style variants of a single arity. Best would be ifFromVariantsreported this as a pretty compile error with proper spans, but even if the implementation of proc macro fails to do that, thenrustcshouldn'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:
Meta
The problem does reproduce both on stable and nightly versions of
rustcandcargo: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=1doesn'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
But here is the full log anyway:
rustc-trace-full.log
The text was updated successfully, but these errors were encountered: