`#[deriving(Clone)]` et al. should ask for `Clone` bounds on fields, not on generic parameters

[japaric]

For example:

#[deriving(Clone)]
struct Filter<A, I, P> where I: Iterator<A>, P: FnMut(&A) -> bool {
    it: I,
    p: P,
}

expands to:

impl<A: Clone, I: Clone, P: Clone> Clone for Filter<A, I, P> where /* .. */ { /* .. */ }

The A: Clone bound is incorrect. Instead deriving should expand to:

impl<A, I, P> Clone for Filter<A, I, P> where
    I: Clone,
    P: Clone,
    /* .. */ { /* .. */ }

This requires generalized where clauses to handle more complex fields like &'a T: Clone.

@nikomatsakis Are where clauses like &'a int: Clone (note: no generic parameter) going to be allowed? If not, writing the syntax extension is going to be harder.

[jroesch]

@japaric currently we accept both forms but as Niko pointed out the RFC technically disallows the bounding of arbitrary types, so the second bound (&'a int: Clone) is currently valid, but technically illegal. I don't see any reason why it is not possible to have the second form, @nikomatsakis would have to fill you in on his thinking. There is a corresponding issue for fixing this behavior: #20019

[eddyb]

@jroesch the good news is that fixing deriving doesn't need to care about whether or not types that don't contain type params can be bounded. Because it can simply not bound those.

[goffrie]

FWIW, this bug is basically the same as #7671.

[alexcrichton]

I believe @goffrie is right in that this is a dupe of #7671