Make missing_fragment_specifier an error in edition 2024

[tgross35]

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 #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 (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 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 #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?)

Nominating for discussion to get this on the radar.

r? @petrochenkov

Tracking:

• Tracking Issue for Rust 2024: Make missing_fragment_specifier an error #128143