New lint: checking for typos in macro_rules

[sosthene-nitrokey]

What it does

This would lint against use of $smth in the expansion part of a macro_rules! if smth is not a capture. While such a pattern could be used in a recursive macro, it is being phased out, so in practice it is likely an typo, especially if the name of smth is close to an actual capture.

See dzamlo/rust-bitfield#40 for the case that prompted this lint suggestion.

Advantage

• Detect potential bugs in macros.
  Macros are hard to debug and have very little compile-time validity checks. Complex recursive macros are very complex, and can have many rules. Any tool to improve that is good.

Drawbacks

There is a possibility of false positives

Example

macro_rules! testing {
    ($testing:ty)  => {$testin}
}

Will never be usable because testin is not a capture (notice the missing g) is not a capture.

it should instead be written as:

macro_rules! testing {
    ($testing:ty)  => {$testing}
}

[y21]

Implementing such a lint is probably tricky because the AST for macro definitions only has the raw TokenStream available, making it difficult to look for anything (even just finding macro matchers). So this sounds like it'd require some manual parsing.

Other similar lints have done this by looking for expansions, but that doesn't seem viable here since at that point you would get a proper compile error instead

[PatchMixolydic]

This is already caught by the allow-by-default meta_variable_misuse lint in rustc (playground):

warning: unknown macro variable `testin`
 --> src/lib.rs:4:24
  |
4 |     ($testing:ty)  => {$testin}
  |                        ^^^^^^^
  |
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![warn(meta_variable_misuse)]
  |         ^^^^^^^^^^^^^^^^^^^^

[sosthene-nitrokey]

Oh thank you! Though it's sad to see it being allow by default, but it seems like a hard problem to solve.

Maybe this issue should be closed?

[flip1995]

Closing, as already covered by rustc.