Parse `let`s as if they were items for diagnostics. by kpreid · Pull Request #159044 · rust-lang/rust

kpreid · 2026-07-09T23:46:56Z

Partially addresses #92615.
Fixes #101622.

This change provides a precise diagnostic in all cases of let appearing in a context where items but not statements are permitted, and let appearing after an item modifier keyword (pub or final).

It provides a suggestion for replacing let with const (which should be usable interactively in rust-analyzer). It provides advice when the user might have thought final meant what it means in Java (immutable variable declaration).

It also consolidates two existing, less powerful let diagnostics into the new code: one for module bodies, and one for trait/impl bodies.

In order to be able to determine whether a let would parse if written properly, it adds a new parameter to the parsing functions, StmtWouldBeAllowed. This is a bit intrusive and not ideal, but I couldn’t think of a better solution, other than extending FnContext to mean more than it currently does, which seems not necessarily wise.

rustbot · 2026-07-09T23:46:59Z

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

cc @rust-lang/rustfmt

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

cc @fmease

rustbot · 2026-07-09T23:47:01Z

r? @fee1-dead

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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, parser
compiler, parser expanded to 75 candidates
Random selection from 20 candidates

kpreid · 2026-07-09T23:47:34Z

+                        .parse_item(
+                            ForceCollect::Yes,
+                            AllowConstBlockItems::Yes,
+                            StmtWouldBeAllowed::NoOrUnknown,


I don’t like that I had to add a new parameter to parse_item everywhere, but I don’t know what would be better. Probably a new distinct entry point function.

View changes since the review

yeah, I don't like we need to change parse_item everywhere, seems not worth for this diganostic.

kpreid · 2026-07-09T23:51:18Z

Tidy doesn’t like how long this file is now. Should I split it in this PR? Put up a separate PR? Ignore?

View changes since the review

In the absence of outside advice, I have split a new file parser/function.rs out of parser/item.rs to satisfy tidy. I will be happy to make that change in a separate PR if that is preferred.

kpreid · 2026-07-09T23:53:04Z

+        let error = match allow_suggest_stmt {
+            StmtWouldBeAllowed::Yes => {
+                // We are in a function, `const` block, or other context in which a `let`
+                // *would* be allowed, except that we must have parsed some item-modifier


Is there an established term for these keywords like pub and final that appear before the item-kind keyword? I picked “modifier” arbitrarily.

View changes since the review

kpreid · 2026-07-09T23:54:13Z

+            }
+        };
+
+        // FIXME: Ideally, we would have a `ItemKind::Err` that optionally defines a name but


I could try to add this new item kind to this PR if desired.

View changes since the review

This is needed to keep `item.rs` under the length limit.

This change provides a precise diagnostic in all cases of `let` appearing in a context where items but not statements are permitted, and `let` appearing after an item modifier keyword (`pub` or `final`). It provides a suggestion for replacing `let` with `const` (which should be usable interactively in rust-analyzer). It provides advice when the user might have thought `final` meant what it means in Java (immutable variable declaration). It also consolidates two existing, less powerful `let` diagnostics into the new code: one for module bodies, and one for `trait`/`impl` bodies. In order to be able to determine whether a `let` *would* parse if written properly, it adds a new parameter, `StmtWouldBeAllowed`. This is a bit intrusive and not ideal, but I couldn’t think of a better solution, other than extending `FnContext` to mean more than it currently does, which seems not necessarily wise.

rustbot · 2026-07-17T00:43:00Z

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.

fee1-dead · 2026-07-22T03:52:23Z

Sorry to be doing this but I am too swamped IRL to review a diff with this size.

@rustbot reroll

kpreid · 2026-07-23T02:03:45Z

Note that this PR would be much smaller if:

the move of function parsing was in a different PR, or
StmtWouldBeAllowed was not added to many callers, and the needed information was obtained some other way.

I would welcome any guidance as to whether and how to do those things.

rust-bors · 2026-07-24T09:13:32Z

☔ The latest upstream changes (presumably #159814) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

tiif

Sorry for the delay, I tried to take a look at this but this change is too big for an area that I am not very familiar with. I just have a small comment.

@rustbot reroll

View changes since this review

tiif · 2026-07-27T06:47:20Z

This seems weird because there is no let statement here 🤔

This is a .fixed file: it is an edited version of the corresponding .rs file which shows the result of applying a suggestion. This particular suggestion replaced let with const. So, it is correct that the //~^ ERROR shows an error that is not in the file.

chenyukang · 2026-07-28T05:01:20Z

+   | ^^^
+   |
+   = note: `let` cannot be used to define global variables
+   = help: consider using `static` and a `Mutex` instead of `let mut`


why we remove the url link in old stderr, something like

error: expected item, found keyword `let` --> tests/ui/parser/let/suggest-const-for-global-var.rs:1:1 | 1 | let X: i32 = 12; | ^^^ | | | `let` cannot be used for global variables | help: consider using `static` or `const` instead of `let` | = note: for a full list of items that can appear in modules, see <https://doc.rust-lang.org/reference/items.html>

View changes since the review

The link is part of an error path primarily meant for the parser telling the user “You gave me something I don’t recognize at all. Here are the things I do recognize.” But in this case, we know exactly what the syntax means, and it’s just not valid in this context. So, telling the user to browse the full list, looking for something that resembles what they want, is not useful.

That said, it would be easy to put this link back. I just don’t think we should.

chenyukang · 2026-07-28T05:03:31Z

 macro_rules! m {
    () => {
-        let //~ ERROR macro expansion ignores keyword `let` and any tokens following
+        loop //~ ERROR macro expansion ignores keyword `loop` and any tokens following


not sure why you change this test.

View changes since the review

Because using let here would no longer exercise the code path that this test is meant to exercise.

chenyukang · 2026-07-28T05:15:30Z

Note that this PR would be much smaller if:

the move of function parsing was in a different PR, or

StmtWouldBeAllowed was not added to many callers, and the needed information was obtained some other way.

I would welcome any guidance as to whether and how to do those things.

it's better to split the moving of function parsing to another seperate PR, it's better to review.

kpreid · 2026-07-28T05:16:41Z

it's better to split the moving of function parsing to another seperate PR, it's better to review.

I have just done that: #160040

Split function parsing out of `item.rs` to a new module. `item.rs` is approaching the tidy-enforced length limit, and this will make room for new additions. I have split this change out of PR rust-lang#159044 to reduce its complexity (and because this large code move quickly becomes stale).

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 9, 2026

rustbot assigned fee1-dead Jul 9, 2026

rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Jul 9, 2026

This comment has been minimized.

Sign in to view

kpreid force-pushed the pub-let branch from 483a17e to bce8485 Compare July 9, 2026 23:55

kpreid commented Jul 9, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

kpreid force-pushed the pub-let branch from bce8485 to 673f4ca Compare July 13, 2026 01:21

This comment has been minimized.

Sign in to view

kpreid added 3 commits July 16, 2026 17:18

Split function parsing out of item.rs to a new module.

9b460f3

This is needed to keep `item.rs` under the length limit.

Comments about existing code.

0899cb5

kpreid force-pushed the pub-let branch from 673f4ca to bd198e6 Compare July 17, 2026 00:42

rustbot assigned tiif and unassigned fee1-dead Jul 22, 2026

tiif reviewed Jul 27, 2026

View reviewed changes

rustbot assigned chenyukang and unassigned tiif Jul 27, 2026

kpreid mentioned this pull request Jul 28, 2026

Split function parsing out of item.rs to a new module. #160040

Open

chenyukang reviewed Jul 28, 2026

View reviewed changes

kpreid marked this pull request as draft July 28, 2026 15:51

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 Jul 28, 2026

Uh oh!

Uh oh!

Conversation

kpreid commented Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 9, 2026

Uh oh!

rustbot commented Jul 9, 2026

Uh oh!

This comment has been minimized.

kpreid Jul 9, 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!

chenyukang Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

kpreid Jul 9, 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!

kpreid Jul 17, 2026

Choose a reason for hiding this comment

Uh oh!

kpreid Jul 9, 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!

kpreid Jul 9, 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 comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Jul 17, 2026

Uh oh!

fee1-dead commented Jul 22, 2026

Uh oh!

kpreid commented Jul 23, 2026

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

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

tiif Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

kpreid Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

chenyukang Jul 28, 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!

kpreid Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

chenyukang Jul 28, 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!

kpreid Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

chenyukang commented Jul 28, 2026

Uh oh!

kpreid commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

kpreid commented Jul 9, 2026 •

edited by rustbot

Loading

kpreid Jul 9, 2026 •

edited by rustbot

Loading

kpreid Jul 9, 2026 •

edited by rustbot

Loading

kpreid Jul 9, 2026 •

edited by rustbot

Loading

kpreid Jul 9, 2026 •

edited by rustbot

Loading

tiif left a comment •

edited by rustbot

Loading

chenyukang Jul 28, 2026 •

edited by rustbot

Loading

chenyukang Jul 28, 2026 •

edited by rustbot

Loading