#[unsafe_destructor] is excessively unsafe (monomorphizes wrong)

[ben0x539]

struct S<T> { field: T }

#[unsafe_destructor]
impl<T> Drop for S<T> {
    fn drop(&self) {
        println(fmt!("drop %?", self));
    }
}

fn main() {
    let i = 7496034;
    let _s1 = S { field: (&i, 4) };
    let _s2 = S { field: "foo" };
}

prints

drop &{field: "foo"}
drop &{field: "bar"}

I suppose the clue is in the name of that attribute, but I figured this case is worth noting--I expected somewhat more subtle unsafety.

It does the right thing if the destructor refers to the field specifically.

[Aatch]

Hmm, I do see your point, but I'm not sure if this is something we can actually fix. As far as I can tell, this is exactly why generic Drops are unsafe.

I'm not certain though, so I'll let somebody more knowledgeable than I chime in.

[bblum]

This looks suspiciously similar to #2734

[bblum]

There's not really any reason for generic drops to be unsafe. The reason they currently aren't is that because of #4301/#3167, destructors are limited to types that fulfill Owned. But that is too conservative of a requirement -- destructors for polymorphic structs should be fine because the destructor can't treat the generic data as anything that would let it build a cycle (whether as concrete pointers, or through calling typeclass methods).

But here the compiler appears to make the assumption that, because destructorful data shouldn't be polymorphic, it should never need to monomorphize finalize in multiple different ways. I don't think there's any theoretical difficulty here (no dynamic dispatch to drop should be needed), just more machinery needed.

[pnkfelix]

Nominating for maturity milestone 2: backwards-compatible. (Though I could see it also getting thrown in the milestone 1 bin).

Here are the issues that I think this bug identifies:

• As bblum points out, if we are going to support attaching a destructor to polymorphic structs at all (even if only via the unsafe_destructor attribute), we cannot monomorphize such destructors so eagerly.
• As bblum also points out, we might be able to generalize the rules for what types have destructors to support a case like this, and thus not require the unsafe_destructor attribute in this instance.
• We also need to document the unsafe_destructor attribute itself. For example, we need to determine whether it is meant for end-user code in general, or targeted mainly for internal libraries (and the documentation audience is adjusted accordingly). Usage of the attribute crept into the FFI tutorial (in a well-motivated example), but there is no accompanying explanation of the attribute (e.g. how it is to be used, in what manner it is unsafe, etc).

Also, I just want to chime in: That is a very nifty test case. :)

(we may want to create sub-issues for some/all of the bullets above; I just wanted to get them out of my head in the short term.)

[Aatch]

I'd say "well-defined" is fine for this (or at least some related issue). It certainly seems like something that should be well defined.

[bblum]

Actually I think well-covered is the right milestone. (Anybody want to cast a vote for the other two?)

[catamorphism]

De-nominating

[nikomatsakis]

Will not be relevant once #8861 is complete