Skip to content

Do not allow attributes on struct field rest patterns #136490

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

Merged
merged 1 commit into from
Feb 16, 2025

Conversation

Skepfyr
Copy link
Contributor

@Skepfyr Skepfyr commented Feb 3, 2025

Fixes #81282.

This removes support for attributes on struct field rest patterns (the .. bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.

This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.

While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to add support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).

This removes support for attributes on struct field rest patterns (the `..`) from the parser.
Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
@rustbot
Copy link
Collaborator

rustbot commented Feb 3, 2025

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 3, 2025
@jieyouxu jieyouxu added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-parser Area: The lexing & parsing of Rust source code to an AST T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Feb 3, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Feb 3, 2025

This is probably more of a "bug fix", in that we should have been rejecting attributes on struct field rest pattern but we didn't. This may be worth a crater run (even if just for awareness to ping anyone who accidentally accepted this), and possibly a T-lang FCP.

@rustbot label: +I-lang-nominated +I-lang-easy-decision

@rustbot rustbot added I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination I-lang-nominated Nominated for discussion during a lang team meeting. labels Feb 3, 2025
@compiler-errors
Copy link
Member

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 3, 2025
… r=<try>

Do not allow attributes on struct field rest patterns

Fixes rust-lang#81282.

This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.

This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.

While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
@bors
Copy link
Collaborator

bors commented Feb 3, 2025

⌛ Trying commit 3f09a20 with merge 3298c2c...

@bors
Copy link
Collaborator

bors commented Feb 3, 2025

☀️ Try build successful - checks-actions
Build commit: 3298c2c (3298c2ca5e390fd0d104357fdeec514a152a9561)

@compiler-errors
Copy link
Member

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-136490 created and queued.
🤖 Automatically detected try build 3298c2c
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 3, 2025
@craterbot
Copy link
Collaborator

🚧 Experiment pr-136490 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment pr-136490 is completed!
📊 2 regressed and 3 fixed (577338 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Feb 4, 2025
@Skepfyr
Copy link
Contributor Author

Skepfyr commented Feb 5, 2025

Both regressions (and the 3 fixes) look entirely unrelated to me.

@scottmcm

This comment was marked as outdated.

@rfcbot

This comment was marked as outdated.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Feb 5, 2025
@scottmcm

This comment was marked as outdated.

@rfcbot

This comment was marked as outdated.

@traviscross
Copy link
Contributor

@rfcbot reviewed

1 similar comment
@tmandry
Copy link
Member

tmandry commented Feb 5, 2025

@rfcbot reviewed

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Feb 5, 2025

@rfcbot reviewed

Feels in line with our prior practice of removing attributes that were not intended to be accepted.

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 5, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Feb 5, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@traviscross traviscross removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 5, 2025
@compiler-errors compiler-errors added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 6, 2025
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 15, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Feb 15, 2025

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Feb 15, 2025

📌 Commit 3f09a20 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 15, 2025
@ehuss
Copy link
Contributor

ehuss commented Feb 15, 2025

Can you please post a PR to the reference to update it, too?

Skepfyr added a commit to Skepfyr/rust-reference that referenced this pull request Feb 15, 2025
rustc never properly supported attributes in this position so this just
removes them entirely.

See rustc change at: rust-lang/rust#136490
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2025
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#127581 (Fix crate name validation)
 - rust-lang#136490 (Do not allow attributes on struct field rest patterns)
 - rust-lang#136808 (Try to recover from path sep error in type parsing)
 - rust-lang#137055 (rustdoc: Properly restore search input placeholder)
 - rust-lang#137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc)
 - rust-lang#137070 (Do not generate invalid links in job summaries)
 - rust-lang#137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives)
 - rust-lang#137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 16, 2025
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#127581 (Fix crate name validation)
 - rust-lang#136490 (Do not allow attributes on struct field rest patterns)
 - rust-lang#136808 (Try to recover from path sep error in type parsing)
 - rust-lang#137055 (rustdoc: Properly restore search input placeholder)
 - rust-lang#137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc)
 - rust-lang#137070 (Do not generate invalid links in job summaries)
 - rust-lang#137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives)
 - rust-lang#137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 06b2f62 into rust-lang:master Feb 16, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Feb 16, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 16, 2025
Rollup merge of rust-lang#136490 - Skepfyr:no-field-rest-pattern-attrs, r=compiler-errors

Do not allow attributes on struct field rest patterns

Fixes rust-lang#81282.

This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.

This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.

While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
@Skepfyr Skepfyr deleted the no-field-rest-pattern-attrs branch February 16, 2025 22:49
@cuviper cuviper modified the milestones: 1.86.0, 1.87.0 Feb 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-parser Area: The lexing & parsing of Rust source code to an AST disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. T-lang Relevant to the language team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Attributes are silently ignored on .. (rest) in struct pattern (StructPatternEtCetera)