Error recovery after errors during macro expansion is usually futile

[Noratrieb]

Code

// https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=13d58799822d542a2c53296f715ac44c
macro_rules! define {
    (enum $name:ident) => {
        struct $name {}
    };
}

define! {
    struct Hello
}

fn main() {
    Hello;
}

Current output

error: no rules expected the token `struct`
 --> src/main.rs:8:5
  |
1 | macro_rules! define {
  | ------------------- when calling this macro
...
8 |     struct Hello
  |     ^^^^^^ no rules expected this token in macro call
  |
note: while trying to match `enum`
 --> src/main.rs:2:6
  |
2 |     (enum $name:ident) => {
  |      ^^^^

error[E0425]: cannot find value `Hello` in this scope
  --> src/main.rs:12:5
   |
12 |     Hello;
   |     ^^^^^ not found in this scope

Desired output

error: no rules expected the token `struct`
 --> src/main.rs:8:5
  |
1 | macro_rules! define {
  | ------------------- when calling this macro
...
8 |     struct Hello
  |     ^^^^^^ no rules expected this token in macro call
  |
note: while trying to match `enum`
 --> src/main.rs:2:6
  |
2 |     (enum $name:ident) => {
  |      ^^^^

Rationale and extra context

This is a concrete example, but the problem is very general. When macro expansion goes wrong, anything might have not happened as a result, for example defining types and other things. In my experience, this frequently causes cascading useless errors, mostly but not exclusively from name resolution. This makes it very hard to work with the output of cargo check when dealing with macro expansion errors in my experience.

We should, when there are errors during macro expansion, abort compilation after macro expansion without any further recovery. It's impossible to know which errors are actually useful and in many cases there are a lot of useless ones.

With errors during macro expansion I mean any errors that stop macros from being expanded, for example matching mismatches or macros not being found.

Note that errors before macro expansion, like parser errors, tend to be fairly recoverable and we should still do recovery on them, this is specifically about the case where the error count increases during macro expansion.

Other cases

No response

Anything else?

cc @rust-lang/wg-diagnostics

[oli-obk]

Yea I've noticed this, too. I think we just need to do it. I don't really see an argument against it

[Noratrieb]

I would send in a PR if I had the time for it, which I don't, so I'm hoping for someone else to do it :)

[policeakshithreddy]

Is there a chance for me to take the lead on resolving this matter??

[Noratrieb]

sure! just write @rustbot claim

[oli-obk]

My guess is that you'll want to look somewhere in the execution of configure_and_expand (

rust/compiler/rustc_interface/src/passes.rs

Line 147 in 286502c

fn configure_and_expand(

) to find the right place the moment a single expansion round has finished and encountered any errors (you can do that by invoking abort_if_errors).

[Noratrieb]

I don't think abort_if_errors is what we want, I think it's fine to recover from things like early local parser errors. What I'd prefer is checking whether the error count increased during macro expansion.

[oli-obk]

cc @petrochenkov do you have opinions on this?

Should we count (query local if ever necessary) errors to determine whether a macro expansion caused errors? Or do something like borrowck and collect all diagnostics in a Vec to be processed at the end? Or something else?

[estebank]

Keep in mind that as annoying as it is to have the "waves of errors" effect when stages don't have any recovery, it is worse to have the "multitude of useless errors" effect when the recovery logic is incorrect. It's better to stop early for things that we can't fully identify ahead of time, and macro expansion errors is one of the prime examples of that.