Wrong inference for `clone()`

[ice1000]

#[derive(Clone)]
struct Test();
fn test() {
    let t = &Test();
    let t = t.clone();
}

[flodiebold]

Yeah, I've been working on this for a while already (on and off). Getting the method resolution order right is a bit tricky.

The problem is that &T has a Clone implementation as well. So we look at the type &Test, see that it has a Clone implementation, and choose that, never even looking at implementations for Test. What rustc does instead is look at the candidates in order of receiver type, not self type. So it looks first at the implementation for Test, because the clone method has receiver type &Test. Only if that doesn't exist does it try to autoref.

Of course, the second problem here is that we don't support derives yet, so even if the above problem was fixed this would still be inferred this way.

[ice1000]

Ok, but isn't derive simply adds a trait implementation to a type at all? Or is it a bigger problem I don't know?

[flodiebold]

Well, that 'simply' glosses over a few details 🙂 See #1427.