Better error messages for type-errors due to #[deriving].

[huonw]

#[deriving(Trait)] normally relies on the constituent types of the struct or enum also implement Trait, and currently, if they don't, the error messages are unclear. e.g. in the following code, the problem is [f64, .. 3] doesn't implement Clone.

#[deriving(Clone)]
struct V {
    v : [f64, ..3]
}

fn main() {}

tmp.rs:1:11: 1:16 error: mismatched types: expected `[f64, .. 3]` but found `&[f64, .. 3]` (expected vector but found &-ptr)
tmp.rs:1 #[deriving(Clone)]

(This particular error message is because there is a Clone impl for &T, and that one is used if there is no Clone impl for T.)

[alexcrichton]

Closing as dupes of #7622 and #7724 (mainly 7622, though)

[huonw]

I disagree that this is a dup of those two; #7622 is only tangentially related to #[deriving], and just provides a convenient example for this issue. And #7724 is just to put the span on a more informative place, the error message is still wrong.

The specific problem here is every field gets pattern matched with ref, and so x: T has type &T when being used in the body of the derived method; thus any trait that is implemented for <T> ... &T (like Clone) but not T "works", but uses the impl for &T. This means that Clone returns &T, which tries to go in to a field with type T: bam, type error.

This would be resolved if there was a way to specify exactly which instance was desired (so it'd be an proper error message if that instance didn't exist).

[Kimundi]

See #11818

[steveklabnik]

@huonw with #11826 merged, is this fixed?

[huonw]

Looks like it:

#[derive(Clone)]
struct V {
    v : [f64; 100]
}

fn main() {}

<anon>:3:5: 3:19 error: the trait `core::clone::Clone` is not implemented for the type `[f64; 100]`
<anon>:3     v : [f64; 100]
             ^~~~~~~~~~~~~~
note: in expansion of #[derive]
<anon>:1:1: 1:17 note: expansion site

Although it was almost certainly #18578 that got them to be that clear.