in which parentheses are suggested for should-have-been-tuple-patterns

[zackmdavis]

Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.

Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
let a in let a, b = (1, 2);—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of parse_full_stmt).

Instead, let's look for that comma when parsing the pattern, and if we
see it, make-believe that we're parsing the remaining elements in a
tuple pattern, so that we can suggest wrapping it all in parentheses. We
need to do this in a separate wrapper method called on a "top-level"
pattern, rather than within
parse_pat itself, because parse_pat gets called recursively to parse
the sub-patterns within a tuple pattern.

We could also do this for match arms, if let, and while let, but
we elect not to in this patch, as it seems less likely for users to make
the mistake in those contexts.

Resolves #48492.

r? @petrochenkov

[petrochenkov]

PatKind::Ident and sub.is_none here are artificial restrictions.
What we want is to parse PAT, PAT, ..., PAT instead of just PAT and return PatKind::Tuple containing those patterns.
It's not very important if those pattern are identifiers or not - if we can easily recover more, we should do it.
(You may want to modify parse_pat_tuple_elements to return partial result even in case of failure.)

[petrochenkov]

We could also do this for match arms, if let, and while let, but
we elect not to in this patch

If supporting if let and other location means simply using parse_pat_fancy instead of parse_pat, I'd rather use parse_pat_fancy everywhere by default unless it conflicts with something.
Supporting "top level" patterns like if let and while let seems to be a part of the "baseline" to me.

[zackmdavis]

@petrochenkov updated (force-push)

artificial restrictions [...] If supporting if let and other location means simply using parse_pat_fancy instead of parse_pat, I'd rather use parse_pat_fancy everywhere by default

You're right; fixed.

(You may want to modify parse_pat_tuple_elements to return partial result even in case of failure.)

The second commit here (d615130) revives the partial-result type from the abandoned #46721. This lets us check subsequent code that makes use of the destructured variables, which I think is exciting!—

zmd@ReflectiveCoherence:~/Code/rust$ rustc +stage1 recover.rs 
error: unexpected `,` in pattern
 --> recover.rs:2:10
  |
2 |     let a, b = (1, 2);
  |         -^-- help: try adding parentheses: `(a, b)`

error[E0277]: cannot divide `{integer}` by `{float}`
 --> recover.rs:3:15
  |
3 |     let c = a / 1.5;
  |               ^ no implementation for `{integer} / {float}`
  |
  = help: the trait `std::ops::Div<{float}>` is not implemented for `{integer}`

error: aborting due to 2 previous errors

(On master, we never get to the type error because parsing was interrupted by the bad pattern. With the first commit (ed6679c) but without d615130, the compiler will think that a has type ({integer}, {integer}) and that b doesn't exist.)

But there are other situations where autotupling can be misleading:

zmd@ReflectiveCoherence:~/Code/rust$ rustc +stage1 slice.rs 
error: unexpected `,` in pattern
 --> slice.rs:4:10
  |
4 |     let a, b = &[1, 2];
  |         -^-- help: try adding parentheses: `(a, b)`

error[E0658]: non-reference pattern used to match a reference (see issue #42640)
 --> slice.rs:4:9
  |
4 |     let a, b = &[1, 2];
  |         ^^^^ help: consider using a reference: `&a, b`
  |
  = help: add #![feature(match_default_bindings)] to the crate attributes to enable

error[E0308]: mismatched types
 --> slice.rs:4:9
  |
4 |     let a, b = &[1, 2];
  |         ^^^^ expected array of 2 elements, found tuple
  |
  = note: expected type `[{integer}; 2]`
             found type `(_, _)`

error: aborting due to 3 previous errors

(The E0658 suggestion is wrong, and the E0308 diagnostic in isolation makes it look like we support Python-like parenless tuples, which we don't.)

What do you think?

[zackmdavis]

(Travis failure is only because I rebased on master without being aware of #48449.)

[zackmdavis]

On further thought, I'm leaning toward the position that the incongruous type errors "downstream" are bad enough that we actually shouldn't try to recover more than the original error did. That is: parse_top_level_pat should return an Err (preventing us from parsing further) rather than just emitting a diagnostic and returning Ok ... still eager for reviewers' thoughts, though.

[estebank]

@zackmdavis I agree with your assessment. Another (more involved) option would be to set the type of the tuple elements to TyErr and continue, but doing this would be non-trivial. If we try to go down that route, I'd rather do so in a follow up PR as part of a full revamp (piece meal improvement towards this in #46732).

In the meantime, I think it is very reasonable to bail out on the enclosing scope and continue (what you're doing). That way the rest of the code will be type checked.

[zackmdavis]

(force-pushed a more conservative version that returns Err in accordance with previous two comments)

r? @estebank

[petrochenkov]

Recovery is not required to be 100% correct, it's guessing by definition, it should only be correct in most cases.
If the let a, b = [1, 2] mistake is relatively rare in practice compared to let a, b = (1, 2) mistake, then we can issue extra diagnostics for it.

That said, even without recovery this is a nice improvement.
@bors r+

[bors]

📌 Commit a36e77c has been approved by petrochenkov

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Provide context for missing comma in match arm and if statement without block #48338

[bors]

📌 Commit a36e77c has been approved by petrochenkov

[kennytm]

@bors r-

The parse_pat_tuple_elements function was recently removed in #48500, replaced by parse_parenthesized_pat_list. Please rebase and update the code.

[zackmdavis]

(rebased)

[estebank]

The rebase seems to have messed the parsing up:

[01:12:28] 2	  --> $DIR/issue-48492-tuple-destructure-missing-parens.rs:48:17
[01:12:28] 3	   |
[01:12:28] 4	LL |     while let b1, b2, b3 = reading_frame.next().expect("there should be a start codon") {
[01:12:28] -	   |               --^------- help: try adding parentheses: `(b1, b2, b3)`
[01:12:28] +	   |               --^
[01:12:28] +	   |               |
[01:12:28] +	   |               help: try adding parentheses: `(b1,)`

[petrochenkov]

I'd keep fn parse_parenthesized_pat_list but factor out fn parse_pat_list out of it and use it here.

[zackmdavis]

Thanks.

[zackmdavis]

(updated)

[estebank]

@bors r+ rollup

[bors]

📌 Commit 1f04597 has been approved by estebank