Implement forced keywords (`k#`) - #161775

fmease · 2026-08-25T16:46:21Z

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.

The ident in k#ident must be a keyword (from any edition) or a weak/contextual keyword for the token to be valid.

What won't be done in this PR:

implementing forced keyword lifetimes ('k#static)
migrating away from built-in syntax builtin # $ident($($tt)*) / introducing k#-exclusive (weak) keywords
- that'll be done in PR Replace builtin # with k# #162232 instead
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
extending the proc_macro::Ident API to allow users to programmatically create forced keywords (might never be added)

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

fmease · 2026-08-25T16:46:44Z

@bors try @rust-timer queue

Implement forced keywords (`k#`)

fmease · 2026-08-25T17:19:35Z

    /// Traits for function pointers and items
    (unstable, fn_static, "CURRENT_RUSTC_VERSION", Some(148768)),
+    /// Allows using forced keywords `k#fn`.
+    (unstable, forced_keywords, "CURRENT_RUSTC_VERSION", Some(153839)),


I've intentionally not marked it internal even though this feature is only backed by a T-compiler MCP and not by a T-lang RFC or in-tree experiment:

I would find it a bit weird if we (in a hypothetical future) told users to "please try out" "k#only bounds" or "&k#own types & exprs" (features that would obviously be non-internal) but they'd have to enable an internal feature in tandem (could be perceived as off-putting).

However, I'm okay with switching it to incomplete or even internal if requested.

View changes since the review

No opinion on this.

fmease · 2026-08-25T17:26:11Z

@@ -103,6 +104,26 @@ impl ToInternal<tk::LitKind> for LitKind {
    }
 }



We can't test the roundtripping in the current form of this PR because I haven't added any k#-exclusive weak keywords where it'd be observable if we accidentally dropped k# during encoding&decoding.

I have however tested locally that it works by introducing a new dummy keyword. A hypothetical UI test would have a setup like

use proc_macro::TokenStream; #[proc_macro] pub fn perform(_: TokenStream) -> TokenStream { let stream: TokenStream = "const _: Option<k#never> = None;").parse().unwrap(); // positive //let stream: TokenStream = "fn k#branded() {}").parse().unwrap(); // negative stream.into_iter().collect() // forces encoding+decoding }

View changes since the review

rust-bors · 2026-08-25T17:48:33Z

☀️ Try build successful (CI)
Build commit: 4eb8eac (4eb8eac3e01e4dbc9d58546df979f51a2ac2e5d5)
Base parent: b751e7a (b751e7a48501be14dcd57b4a430b73a0e51a0c52)

rust-timer · 2026-08-25T18:30:41Z

Finished benchmarking commit (4eb8eac): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.3%, -0.2%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -3.0%, secondary 1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.5%, 3.1%]	2
Improvements ✅ (primary)	-3.0%	[-4.1%, -1.9%]	3
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-3.0%	[-4.1%, -1.9%]	3

Cycles

Results (primary 2.1%, secondary -1.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.2%	[-4.1%, -2.3%]	2
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Binary size

Results (primary 0.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.1%]	4
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	4
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	2
All ❌✅ (primary)	0.0%	[-0.1%, 0.1%]	8

Bootstrap: 477.576s -> 469.017s (-1.79%)
Artifact size: 400.35 MiB -> 400.38 MiB (0.01%)

fmease · 2026-08-27T14:32:58Z

Ready for review.

Caution

Only review the commits created after ------------------------- BRANCH SEPARATOR -------------------------.
That's because this PR is stacked on top of PR #161792. Hence, it's marked S-blocked Status: Blocked on something else such as an RFC or other implementation work. .

Best reviewed commit by commit.

rustbot · 2026-08-27T14:33:10Z

Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs

cc @ZuseZ4

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

cc @rust-lang/rust-analyzer

…rochenkov Move parse error recovery for expression operators "out of line" & refactor in the area **Background**: While we do have 3k-line module `rustc_parse/src/parser/diagnostics.rs`[^1] dedicated to syntax error diagnostics & parse error recovery, the rest of the parser is still "littered" or "interwoven" through and through with complex or verbose diagnostic code. We support numerous recoveries from syntaxes found in other languages right next to code that actually decides what is and what isn't part of Rust syntactically. This makes the parser code very messy, illegible, bug prone and otherwise hard to maintain. So my long-term plan is to push all this diagnostic & recovery code "out of line", namely into new `rustc_parse/src/parser/$fragment/diagnostics.rs` files, to keep the "inline code" of parsing routines in `$fragment.rs` focused on actually parsing Rust code. Why not just use the pre-existing `parser/diagnostics.rs` module? Well, making diagnostic code for expressions, patterns, types etc. share the same module is the definition of a hodgepodge. Moreover, moving all diagnostic code there would make the file way too large. Of course, for common code (if any) `parser/diagnostics.rs` would remain suitable. Best reviewed commit by commit. Commit [Refactor check_assoc_op to make it more legible](rust-lang@66311aa) was cherry-picked from my PR rust-lang#161775. (No LLM was or will be used by me during the entire creation process of this PR) [^1]: Not to be confused with `rustc_parse/src/diagnostics.rs` which holds diagnostic structs.

Rollup merge of #162591 - fmease:out-of-line-recovery, r=petrochenkov Move parse error recovery for expression operators "out of line" & refactor in the area **Background**: While we do have 3k-line module `rustc_parse/src/parser/diagnostics.rs`[^1] dedicated to syntax error diagnostics & parse error recovery, the rest of the parser is still "littered" or "interwoven" through and through with complex or verbose diagnostic code. We support numerous recoveries from syntaxes found in other languages right next to code that actually decides what is and what isn't part of Rust syntactically. This makes the parser code very messy, illegible, bug prone and otherwise hard to maintain. So my long-term plan is to push all this diagnostic & recovery code "out of line", namely into new `rustc_parse/src/parser/$fragment/diagnostics.rs` files, to keep the "inline code" of parsing routines in `$fragment.rs` focused on actually parsing Rust code. Why not just use the pre-existing `parser/diagnostics.rs` module? Well, making diagnostic code for expressions, patterns, types etc. share the same module is the definition of a hodgepodge. Moreover, moving all diagnostic code there would make the file way too large. Of course, for common code (if any) `parser/diagnostics.rs` would remain suitable. Best reviewed commit by commit. Commit [Refactor check_assoc_op to make it more legible](66311aa) was cherry-picked from my PR #161775. (No LLM was or will be used by me during the entire creation process of this PR) [^1]: Not to be confused with `rustc_parse/src/diagnostics.rs` which holds diagnostic structs.

Move parse error recovery for expression operators "out of line" & refactor in the area **Background**: While we do have 3k-line module `rustc_parse/src/parser/diagnostics.rs`[^1] dedicated to syntax error diagnostics & parse error recovery, the rest of the parser is still "littered" or "interwoven" through and through with complex or verbose diagnostic code. We support numerous recoveries from syntaxes found in other languages right next to code that actually decides what is and what isn't part of Rust syntactically. This makes the parser code very messy, illegible, bug prone and otherwise hard to maintain. So my long-term plan is to push all this diagnostic & recovery code "out of line", namely into new `rustc_parse/src/parser/$fragment/diagnostics.rs` files, to keep the "inline code" of parsing routines in `$fragment.rs` focused on actually parsing Rust code. Why not just use the pre-existing `parser/diagnostics.rs` module? Well, making diagnostic code for expressions, patterns, types etc. share the same module is the definition of a hodgepodge. Moreover, moving all diagnostic code there would make the file way too large. Of course, for common code (if any) `parser/diagnostics.rs` would remain suitable. Best reviewed commit by commit. Commit [Refactor check_assoc_op to make it more legible](rust-lang/rust@66311aa) was cherry-picked from my PR rust-lang/rust#161775. (No LLM was or will be used by me during the entire creation process of this PR) [^1]: Not to be confused with `rustc_parse/src/diagnostics.rs` which holds diagnostic structs.

…enkov Prepare for the introduction of forced keywords (`k#`) Split out of PR rust-lang#161775 as requested here: rust-lang#161775 (comment). These changes aren't super well-motivated in isolation IMO but it makes reviewing the other PR easier. r? petrochenkov (No LLM was or will be used by me during the entire creation process of this PR)

Rollup merge of #163019 - fmease:prepare-kay-hash, r=petrochenkov Prepare for the introduction of forced keywords (`k#`) Split out of PR #161775 as requested here: #161775 (comment). These changes aren't super well-motivated in isolation IMO but it makes reviewing the other PR easier. r? petrochenkov (No LLM was or will be used by me during the entire creation process of this PR)

Move parse error recovery for expression operators "out of line" & refactor in the area **Background**: While we do have 3k-line module `rustc_parse/src/parser/diagnostics.rs`[^1] dedicated to syntax error diagnostics & parse error recovery, the rest of the parser is still "littered" or "interwoven" through and through with complex or verbose diagnostic code. We support numerous recoveries from syntaxes found in other languages right next to code that actually decides what is and what isn't part of Rust syntactically. This makes the parser code very messy, illegible, bug prone and otherwise hard to maintain. So my long-term plan is to push all this diagnostic & recovery code "out of line", namely into new `rustc_parse/src/parser/$fragment/diagnostics.rs` files, to keep the "inline code" of parsing routines in `$fragment.rs` focused on actually parsing Rust code. Why not just use the pre-existing `parser/diagnostics.rs` module? Well, making diagnostic code for expressions, patterns, types etc. share the same module is the definition of a hodgepodge. Moreover, moving all diagnostic code there would make the file way too large. Of course, for common code (if any) `parser/diagnostics.rs` would remain suitable. Best reviewed commit by commit. Commit [Refactor check_assoc_op to make it more legible](rust-lang/rust@66311aa) was cherry-picked from my PR rust-lang/rust#161775. (No LLM was or will be used by me during the entire creation process of this PR) [^1]: Not to be confused with `rustc_parse/src/diagnostics.rs` which holds diagnostic structs.

Prepare for the introduction of forced keywords (`k#`) Split out of PR rust-lang/rust#161775 as requested here: rust-lang/rust#161775 (comment). These changes aren't super well-motivated in isolation IMO but it makes reviewing the other PR easier. r? petrochenkov (No LLM was or will be used by me during the entire creation process of this PR)

rustbot · 2026-09-22T22:00:51Z

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-09-22T22:08:23Z

They don't require any language process unlike the primary change

The primary (now only) commit doesn't require any "language process" either if you mean "T-lang interaction" by that.

That's because it's completely unstable, doesn't break any stable code & is fully backed by a compiler MCP which is enough (no T-lang shepherd / T-lang blessed in-tree experiment needed, cf. the builtin # syntax situation).

The change cannot be observed by stable users, neither syntactically nor lexically: Identifier prefixes are reserved in Rust >=2021 (i.e., hard errors) & forced keywords are pre-expansion feature gated. In Rust <2021, k#ident continues to decompose into k # ident & won't be treated as a forced keyword.

@rustbot review

petrochenkov · 2026-09-25T16:39:03Z

+//@ edition: 2021..
+
+#[cfg(false)]
+k#fn start() {} //~ ERROR forced keywords are experimental


Could you check that it's gated in macro arguments as well?

drop_tokens!(k#fn);

View changes since the review

And also that macro m(k#fn) {} doesn't accept fn, and vice versa (that's how it works for raw identifiers now too).

petrochenkov · 2026-09-25T16:42:38Z

+compound_traits!(struct Ident<Span, Symbol> { sym, kind, span });
+
+#[derive(Copy, Clone, Eq, PartialEq)]
+pub enum IdentKind {


(This stuff should have belonged to the previous PR ideally.)

View changes since the review

petrochenkov · 2026-09-25T17:03:59Z

+    Err(dcx.struct_span_err(
+        span,
+        format!(
+            "`${{concat(..)}}` currently does not support {}",


Suggested change

"`${{concat(..)}}` currently does not support {}",

"`${{concat(..)}}` currently does not support {what}",

Nit: a new variable for the match will allow using string interpolation and make the code formatting nicer.

View changes since the review

petrochenkov · 2026-09-25T17:24:05Z

r? @petrochenkov

petrochenkov · 2026-09-25T21:54:15Z

+                    if span.edition().at_least_rust_2021() {
+                        let sym = nfc_normalize(self.str_from(start + BytePos(2)));
+                        self.psess.symbol_gallery.insert(sym, span);
+                        if !sym.can_be_forced_keyword() {


This logic is breaking through abstraction layers, that's why we have issues with weak keywords and similar.

Here we are working with token streams, and at token stream / token tree level there are no keywords.
Keywords only appear when we start parsing some grammar from a token stream, e.g. standard Rust keywords when we start parsing Rust code, or entirely different keyword set specific to a macro x when we start parsing that macro's input.

So ideally my_macro!(k#non_keyword) would be just accepted by the compiler, and the macro itself would decide which tokens to accept in its input and which reject.

When parsing the Rust grammar proper I think it's safe to treat k#non_keyword in the same way as an unused reserved identifier (like virtual, for example). Like, it's a keyword, but there are no language constructions that use it. (But my_macro!(virtual) may work because my_macro's input language may have such keyword.)

In any case this is not very urgent, because it's a conservative error that can be relaxed at any time.

View changes since the review

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 25, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Aug 25, 2026

Auto merge of #161775 - fmease:kay-hash, r=<try>

4eb8eac

Implement forced keywords (`k#`)

This comment has been minimized.

Sign in to view

fmease force-pushed the kay-hash branch from 421efcd to d0c5d34 Compare August 25, 2026 17:12

fmease commented Aug 25, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

fmease force-pushed the kay-hash branch from d0c5d34 to 4aee2b5 Compare August 25, 2026 17:54

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 25, 2026

This comment has been minimized.

Sign in to view

fmease force-pushed the kay-hash branch 2 times, most recently from 9e590de to 1de8681 Compare August 27, 2026 14:25

fmease added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Aug 27, 2026

fmease changed the title ~~Implement forced keywords (k#)~~ [STACKED] Implement forced keywords (k#) Aug 27, 2026

fmease marked this pull request as ready for review August 27, 2026 14:33

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 Aug 27, 2026

rustbot assigned jackh726 Aug 27, 2026

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

This comment has been minimized.

Sign in to view

fmease force-pushed the kay-hash branch from add8c1f to 68f35d4 Compare September 19, 2026 13:54

This comment has been minimized.

Sign in to view

fmease mentioned this pull request Sep 19, 2026

Prepare for the introduction of forced keywords (k#) #163019

Merged

This comment has been minimized.

Sign in to view

fmease force-pushed the kay-hash branch from 68f35d4 to 450b77a Compare September 22, 2026 22:00

Implement forced keywords

450b77a

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 Sep 22, 2026

petrochenkov reviewed Sep 25, 2026

View reviewed changes

rustbot unassigned jackh726 Sep 25, 2026

petrochenkov reviewed Sep 25, 2026

View reviewed changes

petrochenkov 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 Sep 25, 2026

		@@ -103,6 +104,26 @@ impl ToInternal<tk::LitKind> for LitKind {
		}
		}

	"`${{concat(..)}}` currently does not support {}",
	"`${{concat(..)}}` currently does not support {what}",

Uh oh!

Conversation

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

Uh oh!

Uh oh!

fmease commented Aug 25, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

fmease Aug 25, 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!

petrochenkov Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Aug 25, 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!

This comment has been minimized.

rust-bors Bot commented Aug 25, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Aug 25, 2026

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

This comment has been minimized.

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

Uh oh!

Uh oh!

rustbot commented Aug 27, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Sep 22, 2026

Uh oh!

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

Uh oh!

Uh oh!

petrochenkov Sep 25, 2026 • 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!

petrochenkov Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

petrochenkov Sep 25, 2026 • 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!

petrochenkov Sep 25, 2026 • 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!

petrochenkov commented Sep 25, 2026

Uh oh!

petrochenkov Sep 25, 2026 • 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!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

fmease commented Aug 25, 2026 •

edited

Loading

fmease Aug 25, 2026 •

edited

Loading

fmease Aug 25, 2026 •

edited

Loading

fmease commented Aug 27, 2026 •

edited

Loading

fmease commented Sep 22, 2026 •

edited

Loading

petrochenkov Sep 25, 2026 •

edited by rustbot

Loading

petrochenkov Sep 25, 2026 •

edited by rustbot

Loading

petrochenkov Sep 25, 2026 •

edited by rustbot

Loading

petrochenkov Sep 25, 2026 •

edited by rustbot

Loading