Replace `builtin #` with `k#` by fmease · Pull Request #162232 · rust-lang/rust

fmease · 2026-09-03T12:17:33Z

Part of #153839. Also renames internal feature builtin_syntax to internal_syntax (without tombstoning) and keeps/reuses tracking issue #110680 (whose contents are going to get updated post merge).

~~Blocked on #161775 getting picked up by stage0 rustfmt~~ (happened in PR #163483).

_{(No LLM was or will be used by me during the entire creation process of this PR)}

@dianne

Implement forced keywords (`k#`) Part of #153839. CC @dianne Introduces a new token kind to Rust >=2021 that looks like `k#ident` and that is called *forced keyword (identifier)*. This is gated behind a new unstable feature called `forced_keywords`. This is backed by [compiler MCP 945](rust-lang/compiler-team#945). ~~The `ident` in `k#ident` *must* be a keyword (from any edition) or a weak/contextual keyword for the token to be valid.~~ The `ident` in `k#ident` needn't be a keyword to be lexically valid (CC #161775 (comment)). --- What **won't** be done in this PR: 1. implementing forced keyword lifetimes (`'k#static`) 2. migrating away from built-in syntax `builtin # $ident($($tt)*)` / introducing `k#`-exclusive (weak) keywords * that'll be done in PR #162232 instead 3. allowing the user to force edition-dependent & context-dependent keywords to be keywords * re. edition-dependent: forcing them to be keywords even in editions where they're usually not a (strong) keyword (today, that only affects `gen` anyway IINM) * re. context-dependent: E.g., `union` is only "active" if it's followed by a non-reserved identifier and under this PR the same rules apply to `k#union` even though that's not necessary; changing it would result in better diagnostics (e.g., for `k#union struct {}`: `` error: expected item, found `k#union` `` => `` expected identifier, found keyword `struct` ``) and maybe also allow for disambiguation for other context-dependent keywords 4. extending the `proc_macro::Ident` API to allow users to programmatically create forced keywords (might never be added) <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>

@dianne

Implement forced keywords (`k#`) Part of rust-lang/rust#153839. CC @dianne Introduces a new token kind to Rust >=2021 that looks like `k#ident` and that is called *forced keyword (identifier)*. This is gated behind a new unstable feature called `forced_keywords`. This is backed by [compiler MCP 945](rust-lang/compiler-team#945). ~~The `ident` in `k#ident` *must* be a keyword (from any edition) or a weak/contextual keyword for the token to be valid.~~ The `ident` in `k#ident` needn't be a keyword to be lexically valid (CC rust-lang/rust#161775 (comment)). --- What **won't** be done in this PR: 1. implementing forced keyword lifetimes (`'k#static`) 2. migrating away from built-in syntax `builtin # $ident($($tt)*)` / introducing `k#`-exclusive (weak) keywords * that'll be done in PR rust-lang/rust#162232 instead 3. allowing the user to force edition-dependent & context-dependent keywords to be keywords * re. edition-dependent: forcing them to be keywords even in editions where they're usually not a (strong) keyword (today, that only affects `gen` anyway IINM) * re. context-dependent: E.g., `union` is only "active" if it's followed by a non-reserved identifier and under this PR the same rules apply to `k#union` even though that's not necessary; changing it would result in better diagnostics (e.g., for `k#union struct {}`: `` error: expected item, found `k#union` `` => `` expected identifier, found keyword `struct` ``) and maybe also allow for disambiguation for other context-dependent keywords 4. extending the `proc_macro::Ident` API to allow users to programmatically create forced keywords (might never be added) <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>

fmease · 2026-10-14T10:06:54Z

@rustbot reroll

fmease · 2026-10-14T10:19:57Z

Sorry about the pings, y'all. Maybe we should abandon the convention of calling the Symbol of weak / contextual keywords kw::$KeyWord and just call them sym::$keyword like normal symbols...

fmease · 2026-10-14T14:34:16Z

+                // FIXME(deref_patterns, internal_syntax, forced_keywords, clippy):
+                // This should render `k#deref(...)` but unfortunately Clippy uses `pat_to_string`
+                // for the suggestions of its lint `unnested_or_patterns`. Smh fix Clippy to not
+                // rely on AST pretty printing `deref!(…)` for `Deref` patterns and please don't
+                // think about adding a flag to AST pretty to control the output.


Sadly it turns out that Clippy relies on AST pretty for a structured diagnostic suggestion. Well, it's only lint unnested_or_patterns that relies on pat_to_string (since its inception). Clippy already features tests involving deref!(…).

I don't want to handle this right now, so I'm postponing it. I fear the proper solution would be for Clippy to maintain its own pattern printer.

View changes since the review

RalfJung · 2026-10-14T15:35:00Z

Also renames internal feature builtin_syntax to internal_syntax

Is that the best name? Lots of things are "internal", we even have a category of "internal features".

This sounds more like "keyword syntax" to me. The code seems to also call it "forced keywords". So maybe forced_keywords?

fmease · 2026-10-14T16:00:23Z

Also renames internal feature builtin_syntax to internal_syntax

Is that the best name? Lots of things are "internal", we even have a category of "internal features".

This sounds more like "keyword syntax" to me. The code seems to also call it "forced keywords". So maybe forced_keywords?

Feature forced_keywords already exists (guarding k#ident itself) and is orthogonal to builtin_syntax / internal_syntax (guarding a class of internal syntactic constructs). Forced keywords are not just meant for internal features, more importantly they also exist so people can experiment with new keywords without breaking the world (CC only bounds, $expr is $pat, &own, etc.) which is practically motivated.

I consider the name "internal syntax" to be superior to "built-in syntax" because what even is "built-in syntax"? Every syntactic construct is "built-in". Sure, the token streams passed to macros may follow extra syntactic rules that are defined by the macro but that's at a slightly different level of abstraction.

Indeed, we have the concept of "internal features" -- "internal syntax" is a subset thereof / marked as such. I don't see how that is somehow an argument against the name. It's meant to guard a common "run-off-the-mill" class of syntactic constructs that are meant to be internal to the language / standard library. They're an alternative / successor to a certain class of built-in macros.

The only other internal syntaxes besides that are negative bounds !Bound & contract internals contract_ensures / contract_requires.

RalfJung · 2026-10-14T16:20:23Z

Feature forced_keywords already exists (guarding k#ident itself)

Wait, what does internal_syntax guard then? After reading the PR description I thought it guards k#ident. Apparently I got that wrong?

RalfJung · 2026-10-14T16:21:46Z

Oh I see, it guards some particular cases of "keywords" that we never intend to stabilize, as listed in #110680.
Yeah makes sense then, sorry for the noise. :)

rustbot · 2026-10-14T16:47:20Z

rustfmt is developed in its own repository. If possible, consider making this change to rust-lang/rustfmt instead.

cc @rust-lang/rustfmt

fmease added S-blocked Status: Blocked on something else such as an RFC or other implementation work. rla-silenced Silences rust-log-analyzer postings to the PR it's added on. labels Sep 3, 2026

fmease removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 3, 2026

fmease commented Sep 3, 2026

View reviewed changes

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

Comment thread compiler/rustc_span/src/symbol.rs

fmease force-pushed the yeet-builtin-hash branch 2 times, most recently from 7415e73 to 1732079 Compare September 3, 2026 15:23

fmease mentioned this pull request Sep 3, 2026

Implement forced keywords (k#) #161775

Merged