Inconsistent macro repeat operator leads to panic on nightly

[birkenfeld]

Given this test file:

macro_rules! test {
    ($x:ident, $($tt:tt)*) => { $($tt)+ }
}

fn main() {
    test!(x,)
}

stable Rust errors like this:

error: this must repeat at least once
 --> x.rs:2:34
  |
2 |     ($x:ident, $($tt:tt)*) => { $($tt)+ }
  |                                  ^^^^^

error: aborting due to previous error

while on 1.36.0-nightly (50a0def 2019-05-21) running on x86_64-unknown-linux-gnu:

error: internal compiler error: this must repeat at least once
 --> x.rs:2:34
  |
2 |     ($x:ident, $($tt:tt)*) => { $($tt)+ }
  |                                  ^^^^^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:572:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error

[oli-obk]

caused by #60620 cc @mark-i-m

[petrochenkov]

Yay, we have a test case.

[mark-i-m]

Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert #60620 and add the test case. Thanks @birkenfeld !

But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time.

• Checking that the Kleene operator used in the body is the same as that in the matcher
  • https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b440f281efd992b9522275950e5689c2
• Checking that all meta-variables used in the body are defined and in scope
  • https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2d569d0d34213bbab2f1f2a9485546fd
• Checking that all meta-variables used in the body are repeating at the right depth
  • https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c8adccf18462bb0955e786ceb1fdd1b7
• Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway)
  • https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=55fee22139ff7ef1f9470cd048e62885

So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macro macros... @petrochenkov @oli-obk Thoughts?

[mark-i-m]

Opened #61046

[petrochenkov]

there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time.

If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start).

I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).

[mark-i-m]

@petrochenkov Ok, makes sense. I will open another issue with these items so we can track them.