Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
3 tasks done
traviscross opened this issue Jul 24, 2024 · 3 comments
Closed
3 tasks done
Assignees
Labels
A-edition-2024 Area: The 2024 edition C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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
Copy link
Contributor

traviscross commented Jul 24, 2024

This is a tracking issue for:

About 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

Unresolved Questions

None.

Related

@rustbot assign @tgross35

@traviscross traviscross added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. A-edition-2024 Area: The 2024 edition S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-needs-documentation Status: Needs documentation. labels Jul 24, 2024
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 traviscross removed the S-tracking-impl-incomplete Status: The implementation is incomplete. label Jul 29, 2024
@ehuss
Copy link
Contributor

ehuss commented Jul 29, 2024

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 traviscross removed the S-tracking-needs-documentation Status: Needs documentation. label Jul 30, 2024
@traviscross
Copy link
Contributor Author

traviscross commented Jul 30, 2024

@rustbot labels +S-tracking-ready-for-edition

Everything is now merged here, and we can mark this item as being ready for Rust 2024.

Thanks to @tgross35 for pushing this forward and to @ehuss for the documentation here.

@tgross35
Copy link
Contributor

tgross35 commented Jul 30, 2024

Thanks for making this change happen!

@tgross35 tgross35 added the S-tracking-ready-for-edition Status: This issue is ready for inclusion in the edition. label Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2024 Area: The 2024 edition C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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.
Projects
None yet
Development

No branches or pull requests

3 participants