-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE abort due to nested panic while panic-unwinding inside a proc-macro #106298
Comments
cc @TedDriggs (the author of |
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 |
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 <[email protected]> rust-lang/rust#99173 Signed-off-by: Yuki Okushi <[email protected]>
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_variants
crate is1.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 ifFromVariants
reported this as a pretty compile error with proper spans, but even if the implementation of proc macro fails to do that, thenrustc
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:
Meta
The problem does reproduce both on stable and nightly versions of
rustc
andcargo
: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
But here is the full log anyway:
rustc-trace-full.log
The text was updated successfully, but these errors were encountered: