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.

[ojeda]

For context: I ended up seeing this because I used a set of flags which I passed to both rlibs and proc-macros in a custom build system. It was definitely not my intention crashing rustc when a proc macro fails! A warning for --crate-type proc-macro + -Cpanic=abort could be another alternative.

[bjorn3]

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

Proc-macros are run as part of the host process on the main compilation thread. Without -Cpanic=unwind the only way to jump out of the panicking proc macro would be longjmp. Longjmp is UB when there are destructors in any of the skipped frames. Unix systems skip the destructors in this case, but Windows will run any destructors that exist. Because libstd is compiled with -Cpanic=unwind and the proc macro with -Cpanic=abort some things still have a destructor while others don't. LLVM optimizes the proc macro with the expectation that there are no destructors.

I think there are only two possible solutions: Ignore/warn on -Cpanic=abort for proc macros or run the proc macro in a different process. Running the proc macro in a different thread was already enough to cause a non-trivial perf regression I believe.