Change keyword order for `impl` restrictions by CoCo-Japan-pan · Pull Request #155442 · rust-lang/rust

CoCo-Japan-pan · 2026-04-17T14:17:44Z

Based on #155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from pub(...) const unsafe auto impl(...) trait Foo {...} to pub(...) impl(...) const unsafe auto trait Foo {...}.

Tracking issue for restrictions: #105077

r? @Urgau
cc @jhpratt

rustbot · 2026-04-17T14:17:48Z

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

CoCo-Japan-pan · 2026-04-17T16:25:30Z

The auto keyword was accidentally removed from the set of possible tokens, which caused UI tests to fail.
Added check_keyword(exp!(Auto)) in check_trait_front_matter to fix this.
Also removed 2b39bea.

rustbot · 2026-04-18T16:00:48Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

rustbot · 2026-04-18T16:22:48Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

fmease · 2026-04-20T13:58:27Z

+                        // Rule out `const unsafe auto` and `const unsafe trait`
+                        && !self.is_keyword_ahead(2, &[kw::Auto, kw::Trait])


This will regress

#![feature(const_trait_impl)] const unsafe impl Trait for () {} const unsafe trait Trait {}

Can you please revert that change and add a test case for this syntax somewhere in tests/ui/traits/const-traits/?

I know that you added this check in PR #152943 for unrelated reasons but it did silently fix this const-trait-impl issue that I unbeknownst to you originally reported in #148434 (comment) / #146122 (comment). I was aware of that when I reviewed your other PR but didn't mention it which I probably should've.

View changes since the review

470e462
Reverted the change and added a test case.

fmease · 2026-04-20T14:11:39Z

-
-    /// Is this an `(const unsafe? auto? [ impl(in? path) ]? | unsafe auto? [ impl(in? path) ]? | auto [ impl(in? path) ]? | [ impl(in? path) ]?) trait` item?
+    /// Is this an `[impl(in? path)]? const? unsafe? auto? trait` item?
    fn check_trait_front_matter(&mut self) -> bool {


If I'm not mistaken the only conflict with impl blocks we have to avoid is impl (crate) { etc. or am I missing classes of cases? Therefore we only need to ensure that impl(CRATE_OR_SUPER_OR_SELF) is not followed by {.

Well, a negative check might not be liked, so I guess it's alright to keep the "expensive" elaborate suffix checks¹.

View changes since the review

Footnotes

We have a sort of similar situation with impl !Trait for Type {} versus impl ! {} where rustc does a positive check (whether the next token can begin) but where rust analyzer does a negative check (whether it's not {)). ↩

fmease · 2026-04-20T14:21:54Z

+        ];
+        // `impl(`
+        if self.check_keyword(exp!(Impl)) && self.look_ahead(1, |t| t == &token::OpenParen) {
+            // Since the `path` in `impl(in? path)` can be arbitrarily long,


I don't understand the need to perform all this suffix checking if we have in, the sequence impl(in should unambiguously introduce an impl restriction that's its whole purpose; it's a disambiguator. Therefore I'm not sure why we have to assume the worst and perform a tree lookahead.

If the prefix is impl(crate, impl(super or impl(self then and only then do we need to check that it's followed by ) (easy) followed by NOT({) // SUFFIXES.

Or is there a case where impl(in may refer to something other than an impl restriction that I don't know about?

View changes since the review

(For comparison, this is how the keyword order change looks in my own Rust parser: https://github.com/fmease/rasur/pull/34/changes)

Yes, when there is an in, we can immediately return true here.
Still, to recover the cases where in is lost like impl(path::to::module) and suggest to insert the in, I think using tree_look_ahead and check it's suffix is needed for positive tests.

Maybe adding early returns like the following would be good?

// `impl(in` unambiguously introduces an `impl` restriction if self.is_keyword_ahead(2, &[kw::In]) { return true; } // `impl(crate | self | super)` + SUFFIX if self.is_keyword_ahead(2, &[kw::Crate, kw::SelfLower, kw::Super]) && self.look_ahead(3, |t| t == &token::CloseParen) && SUFFIXES.iter().any(|suffix| { suffix.iter().enumerate().all(|(i, kw)| self.is_keyword_ahead(i + 4, &[*kw])) }) { return true; } // Recover cases like `impl(path::to::module)` + SUFFIX to suggest inserting `in`. SUFFIXES.iter().any(|suffix| { suffix.iter().enumerate().all(|(i, kw)| { self.tree_look_ahead(i + 2, |t| { if let TokenTree::Token(token, _) = t { token.is_keyword(*kw) } else { false } }) .unwrap_or(false) }) })

cbba81e
Added early returns for now.

correctly parse `const unsafe trait` implementations.

CoCo-Japan-pan · 2026-04-22T12:01:53Z

Following the positive-check approach for now.
@rustbot ready

fmease

@bors r=Urgau,fmease,jhpratt rollup

View changes since this review

rust-bors · 2026-04-23T11:57:11Z

📌 Commit cbba81e has been approved by Urgau,fmease,jhpratt

It is now in the queue for this repository.

Rollup of 7 pull requests Successful merges: - #155469 (Account for titlecase in casing lints) - #155644 (delegation: support self ty propagation for functions in free to trait reuse) - #154957 (Fix ICE when const closure appears inside a non-const trait method) - #155442 (Change keyword order for `impl` restrictions) - #155561 (Use singular wording for single _ placeholders in type suggestions) - #155637 (Fix E0191 suggestion for empty dyn trait args) - #155661 (Remove `AttributeLintKind` variants - part 6)

@Urgau

Rollup merge of #155442 - CoCo-Japan-pan:impl-restriction-reorder, r=Urgau,fmease,jhpratt Change keyword order for `impl` restrictions Based on #155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`. Tracking issue for restrictions: #105077 r? @Urgau cc @jhpratt

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 Apr 17, 2026

rustbot assigned Urgau Apr 17, 2026

CoCo-Japan-pan force-pushed the impl-restriction-reorder branch from 8e2d081 to 5d955ca Compare April 17, 2026 14:32

This comment has been minimized.

Sign in to view

CoCo-Japan-pan force-pushed the impl-restriction-reorder branch from 5d955ca to 4178059 Compare April 17, 2026 16:21

This comment has been minimized.

Sign in to view

Urgau reviewed Apr 17, 2026

View reviewed changes

Comment thread tests/ui/macros/stringify.rs

Comment thread tests/ui/impl-restriction/recover-incorrect-impl-restriction.rs

Comment thread compiler/rustc_parse/src/parser/item.rs Outdated

Comment thread compiler/rustc_parse/src/parser/mod.rs Outdated

rustbot added T-clippy Relevant to the Clippy team. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Apr 18, 2026

CoCo-Japan-pan force-pushed the impl-restriction-reorder branch 2 times, most recently from 646fa9a to 78cb850 Compare April 18, 2026 16:22

Urgau reviewed Apr 18, 2026

View reviewed changes

Comment thread compiler/rustc_parse/src/parser/item.rs

CoCo-Japan-pan added 5 commits April 19, 2026 15:57

Reorder keywords to place restrictions next to visibility

5621173

Update rustfmt

5d8a297

Update AST pretty printing

a0b8e89

Update HIR pretty printing

614994f

Update UI tests

0e6efe5

CoCo-Japan-pan force-pushed the impl-restriction-reorder branch from 78cb850 to 0e6efe5 Compare April 19, 2026 07:39

fmease mentioned this pull request Apr 20, 2026

Change order of impl restrictions fmease/rasur#34

Merged

fmease reviewed Apr 20, 2026

View reviewed changes

fmease self-assigned this Apr 20, 2026

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 20, 2026

CoCo-Japan-pan added 2 commits April 21, 2026 22:17

Rule out const unsafe impl from FnHeader to

470e462

correctly parse `const unsafe trait` implementations.

Add early returns in check_trait_front_matter

cbba81e

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 22, 2026

jhpratt approved these changes Apr 23, 2026

View reviewed changes

fmease approved these changes Apr 23, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 23, 2026

GuillaumeGomez mentioned this pull request Apr 23, 2026

Rollup of 7 pull requests #155687

Merged

rust-bors Bot merged commit abce9f9 into rust-lang:main Apr 23, 2026
11 checks passed

rustbot added this to the 1.97.0 milestone Apr 23, 2026

Urgau mentioned this pull request Apr 23, 2026

Support impl restriction syntax rust-lang/rust-analyzer#22021

Closed

		// Rule out `const unsafe auto` and `const unsafe trait`
		&& !self.is_keyword_ahead(2, &[kw::Auto, kw::Trait])

Uh oh!

Conversation

CoCo-Japan-pan commented Apr 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 17, 2026

Uh oh!

This comment has been minimized.

CoCo-Japan-pan commented Apr 17, 2026

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Apr 18, 2026

Uh oh!

rustbot commented Apr 18, 2026

Uh oh!

Uh oh!

fmease Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-pan Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

fmease Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Apr 20, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-pan Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-pan Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-pan Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-pan commented Apr 22, 2026

Uh oh!

fmease left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Apr 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

CoCo-Japan-pan commented Apr 17, 2026 •

edited by rustbot

Loading

fmease Apr 20, 2026 •

edited

Loading

fmease Apr 20, 2026 •

edited

Loading

fmease Apr 20, 2026 •

edited

Loading

fmease left a comment •

edited by rustbot

Loading