Tracking issue for future-incompatibility lint missing_fragment_specifier

bc4821f
Opened by Jeffrey Seyfried at 2024-12-21 04:50:10

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

  • [x] https://github.com/rust-lang/rust/pull/39419 introduces the missing_fragment_specifier lint as warn-by-default
  • [x] https://github.com/rust-lang/rust/pull/42894 makes the missing_fragment_specifier lint deny-by-default
  • [ ] #75516 makes the missing_fragment_specifier lint a hard error

  1. 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

    • https://github.com/rust-lang/rust/pull/39419
      • Introduces the missing_fragment_specifier lint as warn-by-default
    • https://github.com/rust-lang/rust/pull/42894
      • Makes the missing_fragment_specifier lint deny-by-default
    • #75516
      • Makes the missing_fragment_specifier lint a hard error
    • #80210
      • Turns the hard error back to a deny-by-default lint due to too much breakage

    León Orell Valerian Liehr at 2024-03-09 20:44:38

  2. 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.

    Stefan Bühler at 2017-07-14 10:08:15

  3. Triage: this is still deny by default.

    Steve Klabnik at 2019-12-25 16:02:38

  4. Given the story behind this I think that a possible course of action would be to promote this to a hard error only on 2021 edition. This would neatly sidestep the breakage observed in the ecosystem.

    cc @rust-lang/compiler @rust-lang/lang

    Esteban Kuber at 2021-01-17 03:29:12

  5. I don't think an edition-specific hard error buys us much over the current situation. I think we should make the lint an error on all editions, but affected by cap-lints - essentially a forbid-by-default lint. That should remove the global state that @matklad wanted to remove and avoid too much complexity, while essentially avoiding any of the known cases where there's breakage.

    I suspect that we could also just make it a hard error in the new edition (no cap-lints) but it's not really necessary IMO, just complicates things.

    Mark Rousskov at 2021-01-17 04:01:06

  6. I think this would be a good fit for cargo report-future-compat once https://github.com/rust-lang/cargo/pull/8825 is merged.

    Aaron Hill at 2021-01-17 19:43:02

  7. I suspect that we could also just make it a hard error in the new edition (no cap-lints) but it's not really necessary IMO, just complicates things.

    I am a fan of promoting lints to hard errors on edition boundaries, despite the implementation burden. It gives us a remarkably powerful tool for language evolution (once we have determined that is the right decision).

    Esteban Kuber at 2021-01-18 01:06:17

  8. I'm doing a lot of typos today thanks to rust-analyzer not working; found this issue through me typing:

    macro_rules! foo { ($x:$ident) => { pub struct $x; } }

    or

    macro_rules! foo { ($x$ident) => { pub struct $x; } }

    playground

    I can't remember ever seeing these kinds of macros this warning issue is for live but it does sound like the parser begins reading another parameter on $[ident] without requiring there to be a comma in between. Should this be reported as a bug or is this good here, maybe getting fixed when hard-error on 2021 happens?

    Joonas Koivunen at 2021-10-14 13:01:03

  9. https://github.com/rust-lang/cargo/pull/8825 has been merged, so this (among many other issues tagged C-future-incompatibility) could be a candidate for becoming a hard error in a future edition.

    Felix S Klock II at 2022-03-07 15:30:37

  10. @koivunej wrote:

    I can't remember ever seeing these kinds of macros this warning issue is for live but it does sound like the parser begins reading another parameter on $[ident] without requiring there to be a comma in between. Should this be reported as a bug or is this good here, maybe getting fixed when hard-error on 2021 happens?

    I'm sorry, I'm not clear on what your comment is asking.

    The two examples you wrote look like buggy code to me, and so I think the lint is correctly firing on them. Can you explain what you think should be happening instead?

    Felix S Klock II at 2022-03-07 15:32:49

  11. @pnkfelix Note that this lint (along with all of the other future-incompat lints) is not included in the future-incompat report by default. That is, the lint will continue to be completely hidden when the crate is compiled as a dependency.

    The only lints that show up in the cargo report are ones marked FutureReleaseErrorReportNow (currently, only PROC_MACRO_BACK_COMPAT and PROC_MACRO_DERIVE_RESOLUTION_FALLBACK).

    Aaron Hill at 2022-03-08 01:10:54

  12. I'm going to reopen since I don't think this should have been closed. It is still a future-incompatible lint generating reports in dependencies. #128006 just changed it in the 2024 edition to be a hard error. Per https://github.com/rust-lang/rust/pull/128006#issuecomment-2251957820, it is still being considered to make this a hard-error in all editions. I think this issue would be as good as any for tracking that final step (and making a decision on it).

    Eric Huss at 2024-07-29 18:07:34

  13. There is a crater run queued for a hard error at https://github.com/rust-lang/rust/pull/128425.

    Trevor Gross at 2024-08-04 00:32:52