Skip to content

Conversation

estebank
Copy link
Contributor

@estebank estebank commented Aug 18, 2025

During let binding parse error and encountering a block, detect if there is a likely missing if or else:

error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
  --> $DIR/missing-if-let-or-let-else.rs:14:25
   |
LL |     let Some(x) = foo() {
   |                         ^ expected one of `.`, `;`, `?`, `else`, or an operator
   |
help: you might have meant to use `if let`
   |
LL |     if let Some(x) = foo() {
   |     ++
help: alternatively, you might have meant to use `let else`
   |
LL |     let Some(x) = foo() else {
   |                         ++++

Fix #107806.

@rustbot
Copy link
Collaborator

rustbot commented Aug 18, 2025

r? @SparrowLii

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

@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 Aug 18, 2025
@chenyukang
Copy link
Member

I'd like to have a review on it
r? @chenyukang

@rust-log-analyzer

This comment has been minimized.

During `let` binding parse error and encountering a block, detect if there is a likely missing `if` or `else`:

```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
  --> $DIR/missing-if-let-or-let-else.rs:14:25
   |
LL |     let Some(x) = foo() {
   |                         ^ expected one of `.`, `;`, `?`, `else`, or an operator
   |
help: you might have meant to use `if let`
   |
LL |     if let Some(x) = foo() {
   |     ++
help: alternatively, you might have meant to use `let else`
   |
LL |     let Some(x) = foo() else {
   |                         ++++
```
@estebank
Copy link
Contributor Author

If we wanted to improve the handling of these, then we would have to actually add a new error recovery AST node, with all the information that an if-let would have and perform validation at the resolve or HIR stage. The purely parser approach I think is likely at the right trade-off between complexity and results.

|
help: you might have meant to use `let else`
|
LL | let Some(x) = foo() else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we suggest add else here, a following error missing ; will comes after applying the fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the correct code maybe:

 let Some(x) = foo() else { 
        return;
 };  // need `;` here

i'm not sure whether we should also suggest the ; at the same time, maybe goes too far.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emm, this code is also valid 😀

fn b() {
    if let Some(x) = foo() {
        return;
    };
}

Copy link
Contributor Author

@estebank estebank Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last example is valid, but unless x is used, then the intent seems muddled. We can of course just suggest if-let in all cases.

Keep in mind that a person is still in the loop. If they didn't mean let-else, then it would give them enough information to realize that the code they wrote wasn't if-let.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, make sense.

@chenyukang
Copy link
Member

@bors r=chenyukang

@bors
Copy link
Collaborator

bors commented Aug 31, 2025

📌 Commit 3af81cf has been approved by chenyukang

It is now in the queue for this repository.

@bors bors 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 Aug 31, 2025
@bors
Copy link
Collaborator

bors commented Aug 31, 2025

⌛ Testing commit 3af81cf with merge 64a99db...

@bors
Copy link
Collaborator

bors commented Aug 31, 2025

☀️ Test successful - checks-actions
Approved by: chenyukang
Pushing 64a99db to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 31, 2025
@bors bors merged commit 64a99db into rust-lang:master Aug 31, 2025
11 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 31, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing cd60c60 (parent) -> 64a99db (this PR)

Test differences

Show 4 test diffs

Stage 1

  • [ui] tests/ui/uninhabited/missing-if-let-or-let-else.rs: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/uninhabited/missing-if-let-or-let-else.rs: [missing] -> pass (J0)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 64a99db105f45ea3304732ffb51066c3b5193bc7 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. pr-check-1: 1359.6s -> 1704.1s (25.3%)
  2. dist-x86_64-apple: 9040.3s -> 7027.6s (-22.3%)
  3. x86_64-gnu-llvm-19: 2432.2s -> 2817.5s (15.8%)
  4. dist-aarch64-apple: 7104.0s -> 6090.5s (-14.3%)
  5. aarch64-apple: 6902.0s -> 5928.7s (-14.1%)
  6. x86_64-rust-for-linux: 2587.8s -> 2931.8s (13.3%)
  7. x86_64-gnu-llvm-19-1: 3377.1s -> 3727.4s (10.4%)
  8. i686-gnu-1: 7526.2s -> 8304.4s (10.3%)
  9. x86_64-gnu-tools: 3389.8s -> 3725.8s (9.9%)
  10. dist-aarch64-msvc: 5554.4s -> 6082.2s (9.5%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (64a99db): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.1% [0.1%, 0.1%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (primary 2.0%)

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

mean range count
Regressions ❌
(primary)
2.0% [2.0%, 2.0%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.0% [2.0%, 2.0%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 466.008s -> 466.641s (0.14%)
Artifact size: 388.55 MiB -> 388.58 MiB (0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

Parse error on let followed by a block should suggest likely alternatives if-let or let-else
7 participants