Tracking issue for future-incompatibility lint `missing_fragment_specifier` #40107

jseyfried · 2017-02-26T03:20:20Z

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

The text was updated successfully, but these errors were encountered:

Bump `clap` to fix the build on new versions of `rustc` (see [rust-lang/rust#42894](rust-lang/rust#42894) and [rust-lang/rust#40107](rust-lang/rust#40107) for details)

stbuehler · 2017-07-14T10:08:15Z

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.

@petrochenkov

Transition some C-future-compatibility lints to {ERROR, DENY} Closes #40107 (ERROR). Closes #39207 (ERROR). Closes #37872 (ERROR). Closes #36887 (ERROR). Closes #36247 (ERROR. Closes #42238 (ERROR). Transitions #59014 (DENY). Transitions #57571 (DENY). Closes #60210 (ERROR). Transitions #35203 (DENY). r? @petrochenkov

steveklabnik · 2019-12-25T16:02:38Z

Triage: this is still deny by default.

…_specifier_hard_error, r=Mark-Simulacrum Revert missing fragment specifier hard error Closes rust-lang#76605 Reopens rust-lang#40107 r? ``@Mark-Simulacrum``

…_specifier_hard_error, r=Mark-Simulacrum Revert missing fragment specifier hard error Closes rust-lang#76605 Reopens rust-lang#40107 r? ```@Mark-Simulacrum```

…pecifier_hard_error, r=Mark-Simulacrum Revert missing fragment specifier hard error Closes rust-lang#76605 Reopens rust-lang#40107 r? `@Mark-Simulacrum`

estebank · 2021-01-17T03:29:12Z

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

Mark-Simulacrum · 2021-01-17T04:01:06Z

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.

Aaron1011 · 2021-01-17T19:43:02Z

I think this would be a good fit for cargo report-future-compat once rust-lang/cargo#8825 is merged.

estebank · 2021-01-18T01:06:17Z

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

koivunej · 2021-10-14T13:01:03Z

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?

pnkfelix · 2022-03-07T15:30:37Z

rust-lang/cargo#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.

pnkfelix · 2022-03-07T15:32:49Z

@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?

Aaron1011 · 2022-03-08T01:10:54Z

@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).

`missing_fragment_specifier` has been a future compatibility warning since 2017. Uplifting it to an unconditional hard error was attempted in 2020, but eventually reverted due to fallout. Make it an error only in edition >= 2024, leaving the lint for older editions. This change will make it easier to support more macro syntax that relies on usage of `$`. Fixes <rust-lang#40107>

…r-e2024, r=petrochenkov Make `missing_fragment_specifier` an error in edition 2024 `missing_fragment_specifier` has been a future compatibility warning since 2017. Uplifting it to an unconditional hard error was attempted in 2020, but eventually reverted due to fallout. Make it an error only in edition >= 2024, leaving the lint for older editions. This change will make it easier to support more macro syntax that relies on usage of `$`. Fixes <rust-lang#40107> --- It is rather late for the edition but since this change is relatively small, it seems worth at least bringing up. This follows a brief [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/.60.20DBD.20-.3E.20hard.20error) (cc `@tmandry).` Making this an edition-dependent lint has come up before but there was not a strong motivation. I am proposing it at this time because this would simplify the [named macro capture groups](rust-lang/rfcs#3649) RFC, which has had mildly positive response, and makes use of new `$` syntax in the matcher. The proposed syntax currently parses as metavariables without a fragment specifier; this warning is raised, but there are no errors. It is obviously not known that this specific RFC will eventually be accepted, but forbidding `missing_fragment_specifier` should make it easier to support any new syntax in the future that makes use of `$` in different ways. The syntax conflict is also not impossible to overcome, but making it clear that unnamed metavariables are rejected makes things more straightforward and should allow for better diagnostics. `@Mark-Simulacrum` suggested making this forbid-by-default instead of an error at rust-lang#40107 (comment), but I don't think this would allow the same level of syntax flexibility. It is also possible to reconsider making this an unconditional error since four years have elapsed since the previous attempt, but this seems likely to hit the same pitfalls. (Possibly worth a crater run?) Tracking: - rust-lang#128143

…e2024, r=petrochenkov Make `missing_fragment_specifier` an error in edition 2024 `missing_fragment_specifier` has been a future compatibility warning since 2017. Uplifting it to an unconditional hard error was attempted in 2020, but eventually reverted due to fallout. Make it an error only in edition >= 2024, leaving the lint for older editions. This change will make it easier to support more macro syntax that relies on usage of `$`. Fixes <rust-lang#40107> --- It is rather late for the edition but since this change is relatively small, it seems worth at least bringing up. This follows a brief [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/.60.20DBD.20-.3E.20hard.20error) (cc `@tmandry).` Making this an edition-dependent lint has come up before but there was not a strong motivation. I am proposing it at this time because this would simplify the [named macro capture groups](rust-lang/rfcs#3649) RFC, which has had mildly positive response, and makes use of new `$` syntax in the matcher. The proposed syntax currently parses as metavariables without a fragment specifier; this warning is raised, but there are no errors. It is obviously not known that this specific RFC will eventually be accepted, but forbidding `missing_fragment_specifier` should make it easier to support any new syntax in the future that makes use of `$` in different ways. The syntax conflict is also not impossible to overcome, but making it clear that unnamed metavariables are rejected makes things more straightforward and should allow for better diagnostics. `@Mark-Simulacrum` suggested making this forbid-by-default instead of an error at rust-lang#40107 (comment), but I don't think this would allow the same level of syntax flexibility. It is also possible to reconsider making this an unconditional error since four years have elapsed since the previous attempt, but this seems likely to hit the same pitfalls. (Possibly worth a crater run?) Tracking: - rust-lang#128143

ehuss · 2024-07-29T18:07:34Z

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 #128006 (comment), 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).

tgross35 · 2024-08-04T00:32:52Z

There is a crater run queued for a hard error at #128425.

steveklabnik added A-compiler T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 1, 2017

steveklabnik removed the A-compiler label Mar 24, 2017

danielrh added a commit to dropbox/rust-brotli-decompressor that referenced this issue Apr 25, 2017

fix rust-lang/rust#40107 warnings

47d4665

Mark-Simulacrum added the C-future-incompatibility Category: Future-incompatibility lints label Jun 20, 2017

petrochenkov changed the title ~~missing_fragment_specifiers future-compatibility warnings~~ missing_fragment_specifier future-compatibility warnings Jul 7, 2017

This was referenced Jul 7, 2017

Fix build on nightly LinuxMercedes/hashpipe#3

Merged

Fix build on nightly zaphar/runwhen#1

Closed

Fix build on nightly adjivas/sem#1

Merged

petrochenkov mentioned this issue Jul 18, 2017

Make sufficiently old or low-impact compatibility lints deny-by-default #42894

Merged

Mark-Simulacrum removed the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 22, 2017

ghost mentioned this issue Sep 14, 2017

Build fails KernelFreeze/Litecraft#2

Closed

dtolnay mentioned this issue May 16, 2018

Simple postfix macros rust-lang/rfcs#2442

Open

This was referenced Aug 3, 2019

missing_fragment_specifier -> hard error #63239

Closed

Transition future compat lints to {ERROR, DENY} #63247

Closed

kentfredric mentioned this issue Sep 26, 2019

error: missing fragment specifier DanielKeep/rust-custom-derive#33

Open

jonas-schievink added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jan 15, 2020

matklad mentioned this issue Aug 1, 2020

Introduce NonterminalKind for more type-safe mbe parsing #74826

Merged

matklad mentioned this issue Aug 14, 2020

Promote missing_fragment_specifier to hard error #75516

Merged

wesleywiser reopened this Dec 26, 2020

nnethercote mentioned this issue Apr 6, 2022

Call compute_locs once per rule #95669

Merged

tmandry added this to Lang Edition 2024 Nov 3, 2023

github-project-automation bot moved this to Idea in Lang Edition 2024 Nov 3, 2023

sosthene-nitrokey mentioned this issue Apr 2, 2024

New lint: checking for typos in macro_rules rust-lang/rust-clippy#12614

Closed

github-actions bot mentioned this issue Apr 9, 2024

rust/1.77.2 package update wolfi-dev/os#16567

Merged

tgross35 mentioned this issue Jul 20, 2024

Make missing_fragment_specifier an error in edition 2024 #128006

Merged

bors closed this as completed in #128006 Jul 27, 2024

ehuss reopened this Jul 29, 2024

fmease changed the title ~~missing_fragment_specifier future-compatibility warnings~~ Tracking issue for future-incompatibility lint missing_fragment_specifier Sep 14, 2024

fmease added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-parser Area: The parsing of Rust source code to an AST C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Sep 14, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for future-incompatibility lint `missing_fragment_specifier` #40107

Tracking issue for future-incompatibility lint `missing_fragment_specifier` #40107

jseyfried commented Feb 26, 2017 •

edited by fmease

Loading

stbuehler commented Jul 14, 2017 •

edited

Loading

steveklabnik commented Dec 25, 2019

estebank commented Jan 17, 2021 •

edited

Loading

Mark-Simulacrum commented Jan 17, 2021

Aaron1011 commented Jan 17, 2021

estebank commented Jan 18, 2021

koivunej commented Oct 14, 2021

pnkfelix commented Mar 7, 2022

pnkfelix commented Mar 7, 2022 •

edited

Loading

Aaron1011 commented Mar 8, 2022

ehuss commented Jul 29, 2024

tgross35 commented Aug 4, 2024

Tracking issue for future-incompatibility lint missing_fragment_specifier #40107

Tracking issue for future-incompatibility lint missing_fragment_specifier #40107

Comments

jseyfried commented Feb 26, 2017 • edited by fmease Loading

What is the warning for?

When will this warning become a hard error?

Current status

stbuehler commented Jul 14, 2017 • edited Loading

steveklabnik commented Dec 25, 2019

estebank commented Jan 17, 2021 • edited Loading

Mark-Simulacrum commented Jan 17, 2021

Aaron1011 commented Jan 17, 2021

estebank commented Jan 18, 2021

koivunej commented Oct 14, 2021

pnkfelix commented Mar 7, 2022

pnkfelix commented Mar 7, 2022 • edited Loading

Aaron1011 commented Mar 8, 2022

ehuss commented Jul 29, 2024

tgross35 commented Aug 4, 2024

Tracking issue for future-incompatibility lint `missing_fragment_specifier` #40107

Tracking issue for future-incompatibility lint `missing_fragment_specifier` #40107

jseyfried commented Feb 26, 2017 •

edited by fmease

Loading

stbuehler commented Jul 14, 2017 •

edited

Loading

estebank commented Jan 17, 2021 •

edited

Loading

pnkfelix commented Mar 7, 2022 •

edited

Loading