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

rust-log-analyzer · 2026-04-17T15:08:00Z

The job aarch64-gnu-llvm-21-1 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

##[endgroup]
Executing "/scripts/stage_2_test_set1.sh"
+ /scripts/stage_2_test_set1.sh
+ '[' 1 == 1 ']'
+ echo 'PR_CI_JOB set; skipping tidy'
+ SKIP_TIDY='--skip tidy'
+ ../x.py --stage 2 test --skip tidy --skip compiler --skip src
PR_CI_JOB set; skipping tidy
##[group]Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.04s
##[endgroup]
---
---- [ui] tests/ui/parser/misspelled-keywords/pub-fn.rs stdout ----
Saved the actual stderr to `/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/parser/misspelled-keywords/pub-fn/pub-fn.stderr`
diff of stderr:
- error: expected one of `#`, `async`, `auto`, `const`, `default`, `enum`, `extern`, `final`, `fn`, `gen`, `impl`, `macro_rules`, `macro`, `mod`, `pub`, `safe`, `static`, `struct`, `trait`, `type`, `unsafe`, or `use`, found `puB`
+ error: expected one of `#`, `async`, `const`, `default`, `enum`, `extern`, `final`, `fn`, `gen`, `impl`, `macro_rules`, `macro`, `mod`, `pub`, `safe`, `static`, `struct`, `trait`, `type`, `unsafe`, or `use`, found `puB`
2 --> $DIR/pub-fn.rs:1:1
3 |
4 LL | puB fn code() {}
- | ^^^ expected one of 22 possible tokens
+ | ^^^ expected one of 21 possible tokens
6 |
7 help: write keyword `pub` in lowercase
8 |
The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args parser/misspelled-keywords/pub-fn.rs`
error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/parser/misspelled-keywords/pub-fn.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/parser/misspelled-keywords/pub-fn" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error: expected one of `#`, `async`, `const`, `default`, `enum`, `extern`, `final`, `fn`, `gen`, `impl`, `macro_rules`, `macro`, `mod`, `pub`, `safe`, `static`, `struct`, `trait`, `type`, `unsafe`, or `use`, found `puB`
##[error] --> /checkout/tests/ui/parser/misspelled-keywords/pub-fn.rs:1:1
|
LL | puB fn code() {}
| ^^^ expected one of 21 possible tokens
|
help: write keyword `pub` in lowercase
|
LL - puB fn code() {}
LL + pub fn code() {}
|

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)]constunsafeimplTraitfor(){}constunsafetraitTrait{}
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` restrictionifself.is_keyword_ahead(2,&[kw::In]){returntrue;}// `impl(crate | self | super)` + SUFFIXifself.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]))}){returntrue;}// 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| {ifletTokenTree::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

@Urgau

…order, r=Urgau,fmease,jhpratt Change keyword order for `impl` restrictions Based on rust-lang#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: rust-lang#105077 r? @Urgau cc @jhpratt

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

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 5d955caCompare April 17, 2026 14:32

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

This comment has been minimized.
Sign in to view

Urgau reviewed Apr 17, 2026
View reviewed changes

Comment threadtests/ui/macros/stringify.rs
Comment threadtests/ui/impl-restriction/recover-incorrect-impl-restriction.rs
Comment threadcompiler/rustc_parse/src/parser/item.rs Outdated
Comment threadcompiler/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 78cb850Compare April 18, 2026 16:22

Urgau reviewed Apr 18, 2026
View reviewed changes

Comment threadcompiler/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 0e6efe5Compare 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-borsBot 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-borsBot merged commit abce9f9 into rust-lang:mainApr 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

fmease mentioned this pull request May 23, 2026
Tracking Issue for Restrictions #105077
Open
11 tasks

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

Uh oh!

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!

rust-log-analyzer commented Apr 17, 2026

Uh oh!

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!

fmeaseApr 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-panApr 21, 2026

Choose a reason for hiding this comment

Uh oh!

fmeaseApr 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!

fmeaseApr 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!

fmeaseApr 20, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-panApr 21, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-panApr 21, 2026

Choose a reason for hiding this comment

Uh oh!

CoCo-Japan-panApr 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-borsBot 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

fmeaseApr 20, 2026•
edited
Loading

fmeaseApr 20, 2026•
edited
Loading

fmeaseApr 20, 2026•
edited
Loading

fmease left a comment •
edited by rustbot
Loading