Copy: Clone has made dropck implementation unsound!

[pnkfelix]

Sample code (playpen):

#![allow(unused_variables, unused_assignments)]

struct D<T:Copy>(T, &'static str);

#[derive(Copy)]
struct S<'a>(&'a D<i32>, &'static str);
impl<'a> Clone for S<'a> {
    fn clone(&self) -> S<'a> {
        println!("cloning `S(_, {})` and thus accessing: {}", self.1, (self.0).0);
        S(self.0, self.1)
    }
}

impl<T:Copy> Drop for D<T> {
    fn drop(&mut self) {
        println!("calling Drop for {}", self.1);
        let _call = self.0.clone();
    }
}

fn main() {
    let (d2, d1);
    d1 = D(34, "d1");
    d2 = D(S(&d1, "inner"), "d2");
}

The Drop Check rule, as specified in RFC 769, requires that no methods be attached to the trait in question. The trait Copy used to qualify under that criteria, but with the addition of the Copy: Clone bound, it no longer does.

The original dropck implementation took a short-cut to enforcing the criteria (by only accepting the known builtin bounds, under the assumption that none had user-defined methods), and so now it is unsound.

[pnkfelix]

To my mind, we should obviously fix the dropck implementation to check for methods properly. (I have a patch that does this; that's how I actually found this problem -- because the regression test I added was also checking that it still accepts Copy, but of course it shouldn't, by the reasoning above.)

The remaining question is: Do we continue to have Copy: Clone? Or does we remove that relationship, at least for the short term (i.e. remove it for the 1.0 release, with the expectation that we would put it back if we had some way of enforcing that the Clone implementation were in fact just the direct copy of the data).

[pnkfelix]

cc @nikomatsakis

[pnkfelix]

triage: P-high

[RalfJung]

Wow, that's surprising - I expected it to be illegal to have a type that is Copy, and has an explicit clone. I mean, is there any usecase for a type where the implicit copies performed by the compiler are different from the explicit copies created by calling clone? I would consider that very surprising, unexpected behavior. Not even C++ allows this: Either you overload the copy constructor, and it is used in all places, or you don't.