Add a lint for catching `clone()` auto(de)ref confusion.

[Kimundi]

Due to auto(de)ref, there are situations where calling clone() on a &T either clones the T, or the &T, depending on whether T has a Clone implementation or not.

This leads to confusing error messages in case of a missing Clone impls, especially in combination with #[deriving(Clone)].

Example

struct Foo; 
let x: Foo = (&Foo).clone();

Fails with

error: mismatched types: expected `main::Foo` but found `&main::Foo` (expected struct main::Foo but found &-ptr)

While this works:

struct Foo; 
impl Clone for Foo { fn clone(&self) -> Foo { Foo } }; 
let x: Foo = (&Foo).clone();

Lint

The proposed lint should catch situations where there are type errors arising from a clone() or deep_clone() call returning &T where T is expected, and recommend implementing Clone or DeepClone for T.

[Kimundi]

Something similar could also get implemented for other traits where this is a problem, like Eq, Ord, etc.

[huonw]

A lint won't help, lints run much after type checking.

I'm going to have another go at fixing deriving properly, so it generates sane error messages, since making compiler generated code have sane error messages via a lint is emphatically the wrong thing to do.

[thestinger]

I don't think this is a solution. It's in no way a problem specific to Clone or a reasonable subset of traits.

[glaebhoerl]

Is #11820 related to this?

Having different methods selected depending on whether or not a particular trait impl exists is exactly the sort of thing which should not happen. The required impl should be unambiguous and in its absence, an error should be reported. I don't have a thorough understanding of this issue. Can someone give me one, or where/how could I get one? Is there a fundamental conflict with auto(de)ref, or is it more a function of the method lookup algorithm?

[Kimundi]

@glaebhoerl: It is a side effect of having auto(de)ref on method call at all, and a generic impl<'a, T: Clone> Clone for &'a T { ... }.

In other words, its the method lookup algorithm doing what it should do: Pick the nearest (in terms of references to add/remove) resolving method.

[steveklabnik]

Triage: nothing has changed. I share skepticism that this is super useful.

[steveklabnik]

Since new lints have a big impact on users of rustc, the policy is that they should go through the RFC process like other user-facing changes. As such, I'm going to give this one a close, but if anyone comes across this ticket and wants this lint, consider adding it to clippy and/or writing up an RFC. Thanks!