rustc_parse: improve the error diagnostic for "missing let" by Unique-Usman · Pull Request #151960 · rust-lang/rust

Unique-Usman · 2026-02-01T17:12:03Z

No description provided.

rustbot · 2026-02-01T17:12:08Z

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

Unique-Usman · 2026-02-01T17:12:25Z

r @estebank

fmease · 2026-02-01T17:22:59Z

tests/ui/inference/issue-103587.rs

    if Some(_) = x {}
-    //~^ ERROR mismatched types
+    //~^ ERROR missing `let`


Wait, this renders if Some(_) = x {} syntactically invalid whereas on main it's merely semantically invalid, right? If so, this constitutes a breaking change and is generally not acceptable¹.

Footnotes

Unless T-lang is in favor of it (which I doubt) and crater is happy ↩

The parser is going to sucessfully parse this, but, the checking happens through the CondCheker(during the parsing process though) as it for all the cond after if and while https://github.com/rust-lang/rust/pull/151960/changes#diff-a278ef012eea7cc71e4c028d8c61c358e7a7cd7e35f846a41c75db09f893b998R4262. Does that constitute to changing from semantically invalidd to synthatically correct ?

If it is, I can limit the changes to

if Some(_) = y && let Some(_) = z

Check if your PR makes rustc reject the following code. If it does, then it's a breaking change.

fn main() { #[cfg(false)] if Some(_) = x {} }

Yeah, it is a breaking change, I think I should remove it. What do you think ?

Yes, we should not introduce any breaking changes.

rustbot · 2026-02-01T17:25:46Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Unique-Usman · 2026-02-01T17:54:19Z

This is a continuation of #151493 as commented in #151493 (comment)

Unique-Usman · 2026-02-01T17:57:48Z

r? @estebank

compiler/rustc_parse/src/parser/expr.rs

tests/ui/missing/missing-let.stderr

Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>

rustbot · 2026-02-07T16:57:34Z

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.

estebank · 2026-02-09T17:24:51Z

@bors r+

rust-bors · 2026-02-09T17:24:55Z

📌 Commit 85ca098 has been approved by estebank

It is now in the queue for this repository.

…estebank rustc_parse: improve the error diagnostic for "missing let"

…uwer Rollup of 7 pull requests Successful merges: - #151960 (rustc_parse: improve the error diagnostic for "missing let") - #152157 (Fix error spans for `asm!()` args that are macros) - #152317 (fix: sup_trace to sub_trace) - #150897 (rustc_parse_format: improve diagnostics for unsupported debug = syntax) - #151154 (Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`) - #152013 (Update to Xcode 26.2) - #152326 (Remove the compiler adhoc group)

Rollup merge of #151960 - Unique-Usman:ua/missingletleft, r=estebank rustc_parse: improve the error diagnostic for "missing let"

…r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. rust-lang#149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. rust-lang#152501 (2026) * caught after merge of rust-lang#149489 * fixed & backported 3. rust-lang#152499 (2026) * caught after merge of rust-lang#149667 * fixed & backported 4. rust-lang#151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. rust-lang#148238 (2025) * caught after merge of rust-lang#118947 * still unaddressed 6. rust-lang#144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. rust-lang#119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. rust-lang#103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say. r? me

…r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. rust-lang#149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. rust-lang#152501 (2026) * caught after merge of rust-lang#149489 * fixed & backported 3. rust-lang#152499 (2026) * caught after merge of rust-lang#149667 * fixed & backported 4. rust-lang#151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. rust-lang#148238 (2025) * caught after merge of rust-lang#118947 * still unaddressed 6. rust-lang#144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. rust-lang#119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. rust-lang#103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm now using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say. r? me

Rollup merge of #153624 - fmease:ping-me-on-parser-changes, r=fmease Ping fmease on parser modifications From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics. I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward. I'm going to list recent examples to paint a picture (note: this is not about blame!): 1. #149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. #152501 (2026) * caught after merge of #149489 * fixed & backported 3. #152499 (2026) * caught after merge of #149667 * fixed & backported 4. #151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. #148238 (2025) * caught after merge of #118947 * still unaddressed 6. #144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. #119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. #103534 (2022) * caught way later * partially addressed Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored. Of course, I'm not able to catch everything. E.g., I didn't notice issue #146417 before PR #139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious #144958 before merge. Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm now using to detect such regressions and issues in general among other things (e.g., #152499 and #152820 were found this way, more to come). I'm pretty invested, let's say. r? me

rustbot assigned fee1-dead Feb 1, 2026

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 Feb 1, 2026

This comment has been minimized.

Sign in to view

fmease requested changes Feb 1, 2026

View reviewed changes

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 1, 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 Feb 1, 2026

Unique-Usman requested a review from fmease February 1, 2026 17:52

rustbot assigned estebank and unassigned fee1-dead Feb 1, 2026

This comment was marked as resolved.

Sign in to view

JayanAXHF added the A-diagnostics Area: Messages for errors, warnings, and lints label Feb 1, 2026

Unique-Usman force-pushed the ua/missingletleft branch from f77bad6 to d1abdc0 Compare February 1, 2026 19:20

Unique-Usman requested a review from estebank February 1, 2026 19:21

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 Feb 1, 2026

estebank reviewed Feb 2, 2026

View reviewed changes

compiler/rustc_parse/src/parser/expr.rs Outdated Show resolved Hide resolved

tests/ui/missing/missing-let.stderr Show resolved Hide resolved

Unique-Usman force-pushed the ua/missingletleft branch from d1abdc0 to d2a30be Compare February 5, 2026 16:42

This comment has been minimized.

Sign in to view

Unique-Usman force-pushed the ua/missingletleft branch from d2a30be to d9c7b1b Compare February 5, 2026 18:38

This comment has been minimized.

Sign in to view

Unique-Usman requested a review from estebank February 5, 2026 18:40

This comment has been minimized.

Sign in to view

rustc_parse: improve the error diagnostic for "missing let"

85ca098

Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>

Unique-Usman force-pushed the ua/missingletleft branch from d9c7b1b to 85ca098 Compare February 7, 2026 16:57

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 Feb 9, 2026

JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 9, 2026

Rollup merge of rust-lang#151960 - Unique-Usman:ua/missingletleft, r=…

af99b0a

…estebank rustc_parse: improve the error diagnostic for "missing let"

This was referenced Feb 9, 2026

Rollup of 17 pull requests #152400

Closed

Rollup of 7 pull requests #152412

Merged

rust-bors bot merged commit 9709215 into rust-lang:main Feb 10, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Feb 10, 2026

rust-timer added a commit that referenced this pull request Feb 10, 2026

Unrolled build for #151960

e6901b2

Rollup merge of #151960 - Unique-Usman:ua/missingletleft, r=estebank rustc_parse: improve the error diagnostic for "missing let"

fmease mentioned this pull request Mar 9, 2026

Ping fmease on parser modifications #153624

Merged

Uh oh!

Conversation

Unique-Usman commented Feb 1, 2026

Uh oh!

rustbot commented Feb 1, 2026

Uh oh!

Unique-Usman commented Feb 1, 2026

Uh oh!

This comment has been minimized.

fmease Feb 1, 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!

Unique-Usman Feb 1, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Feb 1, 2026

Choose a reason for hiding this comment

Uh oh!

Unique-Usman Feb 1, 2026

Choose a reason for hiding this comment

Uh oh!

estebank Feb 1, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Feb 1, 2026

Uh oh!

Unique-Usman commented Feb 1, 2026

Uh oh!

Unique-Usman commented Feb 1, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Feb 7, 2026

Uh oh!

estebank commented Feb 9, 2026

Uh oh!

rust-bors bot commented Feb 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

fmease Feb 1, 2026 •

edited

Loading