Confusing error messages when a pattern match contains .foo() expressions

[Wilfred]

Code

#[derive(Debug, PartialEq)]
enum Pet {
    Dog(String),
}

fn main() {
    let d = Pet::Dog("fido".to_string());

    // Intended.
    assert_eq!(d, Pet::Dog("fido".to_string()));

    // What I wrote by accident.
    assert!(matches!(d, Pet::Dog("fido".to_string())));
}

Current output

error: expected one of `)`, `,`, `...`, `..=`, `..`, or `|`, found `.`
  --> src/main.rs:14:40
   |
14 |     assert!(matches!(d, Pet::Dog("fido".to_string())));
   |                                        ^
   |                                        |
   |                                        expected one of `)`, `,`, `...`, `..=`, `..`, or `|`
   |                                        help: missing `,`

error[E0531]: cannot find tuple struct or tuple variant `to_string` in this scope
  --> src/main.rs:14:41
   |
14 |     assert!(matches!(d, Pet::Dog("fido".to_string())));
   |                                         ^^^^^^^^^ not found in this scope

error[E0023]: this pattern has 2 fields, but the corresponding tuple variant has 1 field
  --> src/main.rs:14:34
   |
3  |     Dog(String),
   |         ------ tuple variant has 1 field
...
14 |     assert!(matches!(d, Pet::Dog("fido".to_string())));
   |                                  ^^^^^^ ^^^^^^^^^^^ expected 1 field, found 2

Desired output

No response

Rationale and extra context

The third message is really confusing: I think rustc has assumed I intended "fido", to_string()? It's surprising to see an error talk about a field with two patterns.

Other cases

No response

Anything else?

No response

[mejrs]

It seems that

matches!(d, Pet::Dog("fido".to_string()));

expands to

match d { Pet::Dog("fido", to_string()) => true, _ => false, };

[fmease]

For the manually expanded match form we now provide a better error message since #118625:

error: expected a pattern, found a method call
  --> src/main.rs:13:24
   |
13 |     match d { Pet::Dog("fido".to_string()) => true, _ => false };
   |                        ^^^^^^^^^^^^^^^^^^ method calls are not allowed in patterns

For the matches! form, nothing has changed because we generally no longer try to recover anything inside of a macro context to prevent issues of the form #103534 (we haven't updated the entirety of the parser yet though that's why the issue is still open). Ideally, we would actually do that but due to the way macro matching is implemented, recovery is oftentimes observable by macros and may lead to breakage.