Skip to content

Recover from tuple patterns with inline element types - #160279

Open
ArneshBanerjee wants to merge 1 commit into
rust-lang:mainfrom
ArneshBanerjee:recover-tuple-type-ascription
Open

Recover from tuple patterns with inline element types#160279
ArneshBanerjee wants to merge 1 commit into
rust-lang:mainfrom
ArneshBanerjee:recover-tuple-type-ascription

Conversation

@ArneshBanerjee

@ArneshBanerjee ArneshBanerjee commented Jul 31, 2026

Copy link
Copy Markdown

If you write the element types inside a tuple pattern:

let (a: bool, b: u8) = (true, 1);

the error you get doesn't really explain the problem:

error: expected one of `)`, `,`, `@`, `if`, or `|`, found `:`
 --> src/main.rs:2:11
  |
2 |     let (a: bool, b: u8) = (true, 1);
  |           ^ expected one of `)`, `,`, `@`, `if`, or `|`

A let pattern can have a type after it, so now we point out what to do instead:

help: to annotate the types of a tuple's elements, write them as a tuple type after the pattern
  |
2 -     let (a: bool, b: u8) = (true, 1);
2 +     let (a, b): (bool, u8) = (true, 1);
  |

If an element doesn't have a type written, it just gets _, so (a: bool, b)
turns into (a, b): (bool, _).

I kept this to let bindings only. That's the case where the pattern doesn't need
a type of its own, so once the types move into the suggestion the rest of the
statement parses fine and you get a single error instead of a pile of follow-up
ones. Match arms, nested patterns and function parameters are left alone.

Closes #149246

Writing the type of each element inside a tuple pattern like
`let (a: bool, b: u8) = ...` isn't valid, but the current error doesn't
really tell you that. It just says "expected one of `)`, `,`, `@`, `if`,
or `|`, found `:`" and leaves you to work it out.

A let pattern can be followed by a type, so we can suggest the fix: move
the types out into a tuple type after the pattern, so `(a: bool, b: u8)`
becomes `(a, b): (bool, u8)`. Elements without a type just get `_`.
Parsing then keeps going with the types dropped, so you only get the one
error.
@rustbot

rustbot commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

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

cc @fmease

@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 Jul 31, 2026
@rustbot

rustbot commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @folkertdev (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue
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 17 candidates

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

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bad recovery from incorrect type ascription syntax in tuples

3 participants