Tracking issue for future-incompatibility lint `missing_fragment_specifier`

[jseyfried]

This is the summary issue for the missing_fragment_specifier future-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made.

What is the warning for?

The missing_fragment_specifier warning is issued when an unused pattern in a macro_rules! macro definition has a meta-variable (e.g. $e) that is not followed by a fragment specifier (e.g. :expr).

This warning can always be fixed by removing the unused pattern in the macro_rules! macro definition.

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.

Current status

• Simplify TokenTree and fix macro_rules! bugs #39419
  • Introduces the missing_fragment_specifier lint as warn-by-default
• Make sufficiently old or low-impact compatibility lints deny-by-default #42894
  • Makes the missing_fragment_specifier lint deny-by-default
• Promote missing_fragment_specifier to hard error #75516
  • Makes the missing_fragment_specifier lint a hard error
• Revert "Promote missing_fragment_specifier to hard error" #75516 #80210
  • Turns the hard error back to a deny-by-default lint due to too much breakage

[stbuehler]

As far as I can tell a macro rule which triggers this warning is not actually usable; is there any reason not to make this an error right now?

See ab91c70cc6:src/libsyntax/ext/tt/macro_parser.rs:384.

Edit: it seems in nightly the lint default was changed to Deny.