Moving out of field error should emit resolution suggestions

[oli-cosmian]

The current error doesn't help users resolve the problem. Even just including a message that one should try borrowing the field by prepending a & would be of help. I don't think it matters that this isn't possible for e.g. self.foo.consuming_method()

struct Foo {
    v: Vec<u32>,
}

impl Foo {
    fn bar(&self) {
        for _ in self.v {
            
        }
    }
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error[E0507]: cannot move out of `self.v` which is behind a shared reference
 --> src/lib.rs:7:18
  |
7 |         for _ in self.v {
  |                  ^^^^^^ move occurs because `self.v` has type `std::vec::Vec<u32>`, which does not implement the `Copy` trait

error: aborting due to previous error

For more information about this error, try `rustc --explain E0507`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

[estebank]

I could have sworn we had it already :-|

[cmpute]

I have a case related to this issue:

use std::ops::Neg;

pub struct Foo<T>(pub T);

impl<T: Neg<Output = T>> Neg for Foo<T> {
    type Output = Self;
    fn neg(self) -> Self {
        Foo(-self.0)
    }
}

impl<T: Neg<Output = T> + Clone> Neg for &Foo<T> {
    type Output = Foo<T>;
    fn neg(self) -> Self::Output {
        Foo(-self.0.clone())
    }
}

// pub fn test0<T: Neg>(f: Foo<T>) -> Foo<T>{
//     f.neg()
// }
// pub fn test1<T: Neg>(f: Foo<T>) -> Foo<T>{
//     -f
// }
pub fn test2<T: Neg<Output = T>>(f: Foo<T>) -> Foo<T>{
    -f
}
// pub fn test3<T: Neg<Output = T>>(f: &Foo<T>) -> Foo<T>{
//     f.neg()
// }
pub fn test4<T: Neg<Output = T> + Clone>(f: &Foo<T>) -> Foo<T>{
    f.neg()
}

(Playground)

In this case, test2 and test4 are correct implementation while the others are incorrect because they lack trait bounds. But the error messages on test1 and test3 are not very helpful.

The error message for test0 is the most helpful one

error[[E0599]](https://doc.rust-lang.org/nightly/error-index.html#E0599): the method `neg` exists for struct `Foo<T>`, but its trait bounds were not satisfied
  --> src/lib.rs:20:7
   |
3  | pub struct Foo<T>(pub T);
   | -------------------------
   | |
   | method `neg` not found for this
   | doesn't satisfy `Foo<T>: Neg`
...
20 |     f.neg()
   |       ^^^ method cannot be called on `Foo<T>` due to unsatisfied trait bounds
   |

The error message for test1 is

error[[E0600]](https://doc.rust-lang.org/nightly/error-index.html#E0600): cannot apply unary operator `-` to type `Foo<T>`
  --> src/lib.rs:20:5
   |
20 |     -f
   |     ^^ cannot apply unary operator `-`

For more information about this error, try `rustc --explain E0600`.

The error message for test3 is

error[[E0507]](https://doc.rust-lang.org/nightly/error-index.html#E0507): cannot move out of `*f` which is behind a shared reference
   --> src/lib.rs:20:5
    |
20  |     f.neg()
    |     ^^-----
    |     | |
    |     | `*f` moved due to this method call
    |     move occurs because `*f` has type `Foo<T>`, which does not implement the `Copy` trait
    |
note: this function takes ownership of the receiver `self`, which moves `*f`

For more information about this error, try `rustc --explain E0507`.

[estebank]

Current output:

error[E0507]: cannot move out of `self.v` which is behind a shared reference
   --> f75.rs:7:18
    |
7   |         for _ in self.v {
    |                  ^^^^^^
    |                  |
    |                  `self.v` moved due to this implicit call to `.into_iter()`
    |                  move occurs because `self.v` has type `Vec<u32>`, which does not implement the `Copy` trait
    |
note: `into_iter` takes ownership of the receiver `self`, which moves `self.v`
   --> /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:268:18
    |
268 |     fn into_iter(self) -> Self::IntoIter;
    |                  ^^^^
help: consider iterating over a slice of the `Vec<u32>`'s content to avoid moving into the `for` loop
    |
7   |         for _ in &self.v {
    |                  +

I believe that we are fully handling the original report. The report on the above comment is unchanged.