Tracking Issue for Rust 2024: Make missing_fragment_specifier an error
#128143
Assignees
Labels
A-edition-2024
Area: The 2024 edition
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
S-tracking-ready-for-edition
Status: This issue is ready for inclusion in the edition.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
traviscross
added
T-lang
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Jul 24, 2024
We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on this feature are reported when used as dependencies. Tracking issue: <rust-lang#128143>
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Jul 24, 2024
We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies. Tracking issue: <rust-lang#128143>
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 24, 2024
…r-unconditional, r=petrochenkov Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps` We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies. Tracking issue: <rust-lang#128143>
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 24, 2024
…r-unconditional, r=petrochenkov Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps` We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies. Tracking issue: <rust-lang#128143>
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 25, 2024
Rollup merge of rust-lang#128122 - tgross35:missing-fragment-specifier-unconditional, r=petrochenkov Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps` We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies. Tracking issue: <rust-lang#128143>
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jul 27, 2024
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 27, 2024
…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
traviscross
removed
the
S-tracking-impl-incomplete
|
Posted edition-guide docs at rust-lang/edition-guide#315, with the expectation that it might need to be reverted if the change is made in all editions. |
traviscross
removed
the
S-tracking-needs-documentation
|
Thanks for making this change happen! |
tgross35
added
the
S-tracking-ready-for-edition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a tracking issue for:
missing_fragment_specifieran error in edition 2024 #128006About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
missing_fragment_specifierasFutureReleaseErrorReportInDeps#128122missing_fragment_specifieran error in edition 2024 #128006Unresolved Questions
None.
Related
missing_fragment_specifieran error in edition 2024 #128006@rustbot assign @tgross35
The text was updated successfully, but these errors were encountered: