rustc crash when proc macro panics if compiled with `-Cpanic=abort`

[ojeda]

Code

Panicking proc macro p.rs:

extern crate proc_macro;

#[proc_macro]
pub fn p(_: proc_macro::TokenStream) -> proc_macro::TokenStream {
    panic!()
}

User m.rs:

extern crate p;
p::p! {}

Then:

$ rustc -Cpanic=abort --crate-type proc-macro p.rs
$ rustc -L. m.rs

Meta

Reproduces in 1.49.0, 1.50.0 as well as nightlies.

Error output

Depends on how the proc macro is compiled. It can range from some output:

$ rustc -Cpanic=abort --crate-type proc-macro p.rs
$ rustc -L. m.rs
fatal runtime error: failed to initiate panic, error 5
(aborted)

To nothing at all:

$ rustc -Cpanic=abort --crate-type proc-macro p.rs -Cforce-unwind-tables=y
$ rustc -L. m.rs
(return code 101)

[ojeda]

By the way, passing -Z proc-macro-backtrace does display an ICE, which is useful to at least know in which line the proc macro failed, e.g.:

thread 'rustc' panicked at 'explicit panic', p.rs:5:5

[ojeda]

@rustbot label: +I-crash, -I-ICE

[Aaron1011]

It might be possible to improve the error message here. However, proc macros are loaded into the compiler process via a shared library, so there's no way for us to 'catch' the abort panic without running proc macros in another process.

[ojeda]

We could make the proc macros' panic-abort not actually abort the process, communicating they are "dead" instead to the host process.

A user passing -Cpanic=abort in a proc macro is likely trying to save space, or was trying to simplify a custom build system, or did it by accident (e.g. see next comment). It is unlikely they were trying to ask to actually abort rustc. Perhaps -Cpanic= shouldn't be supported for --crate-type proc-macro at all.