Bad diagnostic for match ergonomics

[GuillaumeGomez]

This is a reopening of #51743 to not lose track of the diagnostic issue which still remains to this day.

Match ergonomics can create quite confusing errors.

For instance:

fn main() {
    let option = MyOption::MySome(String::new());
    option.take();
}

enum MyOption<T> {
    MyNone,
    MySome(T),
}

impl<T> MyOption<T> {
    fn take(&mut self) -> Option<T> {
        match self {
            MyOption::MySome(value) => {
                *self = MyOption::MyNone;
                Some(value)
            },
            MyOption::MyNone => None,
        }
    }
}

(playground)
gives the following error message:

error[E0308]: mismatched types
  --> src/main.rs:16:22
   |
16 |                 Some(value)
   |                      ^^^^^ expected type parameter, found &mut T
   |
   = note: expected type `T`
              found type `&mut T`

This error message is not even helping the user to figure out what the problem is.
Here, it's like if value was of type &mut T instead of T.

[Centril]

Diagnostic on nightly:

error[E0308]: mismatched types
  --> src/main.rs:16:22
   |
11 | impl<T> MyOption<T> {
   |      - this type parameter
...
16 |                 Some(value)
   |                      ^^^^^ expected type parameter `T`, found `&mut T`
   |
   = note: expected type parameter `T`
           found mutable reference `&mut T`
   = help: type parameters must be constrained to match other types
   = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters

[Centril]

Do you have any suggestions as to what the error message should say in the best of worlds?

[varkor]

I imagine some of these confusing errors are really due to #64586. I think we should try to fix that one.

[GuillaumeGomez]

I think a "bigger" error message explaining what the compiler did and what the user needs to do precisely here might be required.

[Centril]

@GuillaumeGomez That's not really actionable as a specification I could go implement though. Could you try to take the diagnostic on nightly and adjust it to your preference?

[antoyo]

@Centril:
Something along those lines (probably adjusted to take match ergonomics into account, though) that you can get by adding the * to disable the match ergonomics and you get an error that gives a better hint at what to fix:

   Compiling playground v0.0.1 (/playground)
error[E0507]: cannot move out of `self.0` which is behind a mutable reference
  --> src/main.rs:13:15
   |
13 |         match *self {
   |               ^^^^^ help: consider borrowing here: `&*self`
14 |             MyOption::MySome(value) => {
   |                              -----
   |                              |
   |                              data moved here
   |                              move occurs because `value` has type `T`, which does not implement the `Copy` trait

[Centril]

I did some quick investigation of strategies to fix this issue. Unfortunately, the way the type checker is setup today, check_expr_path does not care about the input expected type and is only in synthesis mode (in bidirectional type-checking terms). It is when type checking the Some(_) expression (where _ is a hole for the value path expression) that the actual type error occurs, and so we would have to insert the logic which would consider Res::Local(...) there. But this would also only work for call expressions. We would have to insert similar hacks for many other expression forms, so this would not be a worthwhile change.

[GuillaumeGomez]

This completely goes against the primary purpose of the match ergonomics: making pattern matching borrows simpler. :-/

I don't know how to improve things efficiently considering how complex this would be...

[antoyo]

What about checking in which context (i.e. expected type) the auto-ref value is used and say something like:

help: it looks like you want to move this value, but match ergonomics auto-ref this value

?