Skip to content

Conversation

@jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented Jan 2, 2026

Fixes #149692.

On beta after #146978, we ICE on

macro_rules! m {
    ($id:item()) => {}
}

m!(Self());

where Self in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, Self is a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect #146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).

There's no sensible recovery scheme here, giving up the recovery is the
right thing to do.
@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 Jan 2, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 2, 2026

r? @petrochenkov

rustbot has assigned @petrochenkov.
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

@jieyouxu
Copy link
Member Author

jieyouxu commented Jan 2, 2026

Hm actually wait the previous error message does make sense, it's just the suggestion, let me see.

EDIT: hm, not very convinced it's worth it.

@jieyouxu jieyouxu marked this pull request as draft January 2, 2026 09:53
@rustbot rustbot 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 Jan 2, 2026
@jieyouxu jieyouxu marked this pull request as ready for review January 2, 2026 10:31
@rustbot 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 Jan 2, 2026
@petrochenkov
Copy link
Contributor

@bors r+

@rust-bors 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 Jan 14, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 14, 2026

📌 Commit 79c4727 has been approved by petrochenkov

It is now in the queue for this repository.

JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
rust-bors bot pushed a commit that referenced this pull request Jan 14, 2026
…uwer

Rollup of 12 pull requests

Successful merges:

 - #150585 (Add a context-consistency check before emitting redundant generic-argument suggestions)
 - #150586 (rustdoc: Fix intra-doc link bugs involving type aliases and associated items)
 - #150590 (Don't try to recover keyword as non-keyword identifier )
 - #150817 (cleanup: remove borrowck handling for inline const patterns)
 - #150939 (resolve: Relax some asserts in glob overwriting and add tests)
 - #150966 (rustc_target: Remove unused Arch::PowerPC64LE)
 - #150971 (Disallow eii in statement position)
 - #151016 (fix: WASI threading regression by disabling pthread usage)
 - #151046 (compiler: Make Externally Implementable Item (eii) macros "semiopaque")
 - #151103 (mir_build: Simplify length-determination and indexing for array/slice patterns)
 - #151117 (Avoid serde dependency in build_helper when not necessary)
 - #151127 (Delete `MetaItemOrLitParser::Err`)

r? @ghost
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
rust-bors bot pushed a commit that referenced this pull request Jan 14, 2026
…uwer

Rollup of 16 pull requests

Successful merges:

 - #150585 (Add a context-consistency check before emitting redundant generic-argument suggestions)
 - #150586 (rustdoc: Fix intra-doc link bugs involving type aliases and associated items)
 - #150590 (Don't try to recover keyword as non-keyword identifier )
 - #150817 (cleanup: remove borrowck handling for inline const patterns)
 - #150939 (resolve: Relax some asserts in glob overwriting and add tests)
 - #150962 (Remove `FeedConstTy` and provide ty when lowering const arg)
 - #150966 (rustc_target: Remove unused Arch::PowerPC64LE)
 - #150971 (Disallow eii in statement position)
 - #151016 (fix: WASI threading regression by disabling pthread usage)
 - #151046 (compiler: Make Externally Implementable Item (eii) macros "semiopaque")
 - #151099 (Recover parse gracefully from `<const N>`)
 - #151117 (Avoid serde dependency in build_helper when not necessary)
 - #151127 (Delete `MetaItemOrLitParser::Err`)
 - #151128 (Add temporary new bors e-mail address to the mailmap)
 - #151130 (resolve: Downgrade `ambiguous_glob_imports` to warn-by-default)
 - #151138 (Rename `rust.use-lld` to `rust.bootstrap-override-lld` in INSTALL.md)

r? @ghost
rust-bors bot pushed a commit that referenced this pull request Jan 14, 2026
…uwer

Rollup of 15 pull requests

Successful merges:

 - #150585 (Add a context-consistency check before emitting redundant generic-argument suggestions)
 - #150586 (rustdoc: Fix intra-doc link bugs involving type aliases and associated items)
 - #150590 (Don't try to recover keyword as non-keyword identifier )
 - #150817 (cleanup: remove borrowck handling for inline const patterns)
 - #150939 (resolve: Relax some asserts in glob overwriting and add tests)
 - #150962 (Remove `FeedConstTy` and provide ty when lowering const arg)
 - #150966 (rustc_target: Remove unused Arch::PowerPC64LE)
 - #150971 (Disallow eii in statement position)
 - #151016 (fix: WASI threading regression by disabling pthread usage)
 - #151046 (compiler: Make Externally Implementable Item (eii) macros "semiopaque")
 - #151099 (Recover parse gracefully from `<const N>`)
 - #151117 (Avoid serde dependency in build_helper when not necessary)
 - #151127 (Delete `MetaItemOrLitParser::Err`)
 - #151128 (Add temporary new bors e-mail address to the mailmap)
 - #151138 (Rename `rust.use-lld` to `rust.bootstrap-override-lld` in INSTALL.md)

r? @ghost
@rust-bors rust-bors bot merged commit 9ef7679 into rust-lang:main Jan 15, 2026
11 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Jan 15, 2026
rust-timer added a commit that referenced this pull request Jan 15, 2026
Rollup merge of #150590 - ident-kw-ice, r=petrochenkov

Don't try to recover keyword as non-keyword identifier

Fixes #149692.

On beta after #146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect #146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
@jieyouxu jieyouxu deleted the ident-kw-ice branch January 15, 2026 00:56
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jan 15, 2026
…uwer

Rollup of 15 pull requests

Successful merges:

 - rust-lang/rust#150585 (Add a context-consistency check before emitting redundant generic-argument suggestions)
 - rust-lang/rust#150586 (rustdoc: Fix intra-doc link bugs involving type aliases and associated items)
 - rust-lang/rust#150590 (Don't try to recover keyword as non-keyword identifier )
 - rust-lang/rust#150817 (cleanup: remove borrowck handling for inline const patterns)
 - rust-lang/rust#150939 (resolve: Relax some asserts in glob overwriting and add tests)
 - rust-lang/rust#150962 (Remove `FeedConstTy` and provide ty when lowering const arg)
 - rust-lang/rust#150966 (rustc_target: Remove unused Arch::PowerPC64LE)
 - rust-lang/rust#150971 (Disallow eii in statement position)
 - rust-lang/rust#151016 (fix: WASI threading regression by disabling pthread usage)
 - rust-lang/rust#151046 (compiler: Make Externally Implementable Item (eii) macros "semiopaque")
 - rust-lang/rust#151099 (Recover parse gracefully from `<const N>`)
 - rust-lang/rust#151117 (Avoid serde dependency in build_helper when not necessary)
 - rust-lang/rust#151127 (Delete `MetaItemOrLitParser::Err`)
 - rust-lang/rust#151128 (Add temporary new bors e-mail address to the mailmap)
 - rust-lang/rust#151138 (Rename `rust.use-lld` to `rust.bootstrap-override-lld` in INSTALL.md)

r? @ghost
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ICE parse_expected_identifier_found_keyword_str

3 participants