dropck can be bypassed via a trait object method

[arielb1]

STR

// Using this instead of Fn etc. to take HRTB out of the equation.
trait Trigger<B> { fn fire(&self, b: &mut B); }
impl<B: Button> Trigger<B> for () {
    fn fire(&self, b: &mut B) {
        b.push();
    }
}

// Still unsound Zook
trait Button { fn push(&self); }
struct Zook<B> { button: B, trigger: Box<Trigger<B>+'static> }

impl<B> Drop for Zook<B> {
    fn drop(&mut self) {
        self.trigger.fire(&mut self.button);
    }
}

// AND
struct Bomb { usable: bool }
impl Drop for Bomb { fn drop(&mut self) { self.usable = false; } }
impl Bomb { fn activate(&self) { assert!(self.usable) } }

enum B<'a> { HarmlessButton, BigRedButton(&'a Bomb) }
impl<'a> Button for B<'a> {
    fn push(&self) {
        if let B::BigRedButton(borrowed) = *self {
            borrowed.activate();
        }
    }
}

fn main() {
    let (mut zook, ticking);
    zook = Zook { button: B::HarmlessButton,
                  trigger: Box::new(()) };
    ticking = Bomb { usable: true };
    zook.button = B::BigRedButton(&ticking);
}

This fails the assertion. cc @pnkfelix. I think the problem here is that Box<Trigger<B>+'static> does not require that B: 'static (cc @nikomatsakis).

[alexcrichton]

triage: I-nominated

[nikomatsakis]

Hmm, so I don't think that the problem has to do with Trigger<B>: 'static requiring that B: 'static per se, though I suppose it might help with the problem. Rather, it seems to be a flaw in the "parametricity" argument -- that is, today, we consider the definition of drop "uninteresting" if B does not have any bounds, with the intention of screening out code that treats instances of B opaquely. But we overlooked closures or trait objects that may consume a B instance and which (hence) "encapsulate" bounds. That's...pretty unfortunate.

[nikomatsakis]

After thinking on this last night, I laid it out in my head this way. There is a properly very similar to variance, let's call it "Type may access X" where X is one of the type parameters declared on Type. It indicates whether having access to a Type<Foo> potentially lets you manipulate the contents of Foo. This can be inferred in a global way just as variance can be inferred by setting up various constraints. The bottom line is what kind of data is reachable through Type.

For convenience, we also write T<...,U,...> may access U to mean T may access V where V is the type parameter for which U is being substituted.

Given some type declared like struct Type<..., X, ...> (possibly with where clauses):

• If Type has where-clauses that reference X, then Type may access X.
• If the definition of Type contains a field f: T where T contains (somewhere) Type1<..., X, ...>, and Type1<...X...> may access X, then Type may access X.

In addition there are some ground rules:

• fn(..., X, ...) may access X
• Trait<...X,...> may access X

Now the dropck can use these rules to decide when it should enforce stricter rules. In particular, if an lvalue of type T<U> is being dropped at exit from 'a, and T<U> may access U, then U must strictly outlive 'a. Or something like that, I have to review how the dropck rules are formulated exactly. But you get the idea.

The key point is that this property may access is independent from whether a value has a destructor. The intution is "if a destructor got ahold of a value of type T<...U...>, could it wind up dereferencing pointers in U?"

[nikomatsakis]

Some implications of this, presuming this property is inferred in a similar fashion to variance:

• adding a fn or trait object into a type can be a breaking change. That worried me some, but I realized that it is likely true already, since it also affects the variance calculation (triggers invariance). Now I still worry but less.

[arielb1]

Personally I think of the issue as being more related to liveness - every lifetime parameter to a function (or impl) is required to be alive when the function (that can access that impl) is called, but (because of dropck) type parameters passed to a function may not be alive. This is preserved by normal selection (as it can't dig into the dead type and find the dead lifetime), but trait objects (and equivalently, instantiations of generic functions) can "refer to" an impl that witnesses the liveness of the lifetime, and should be treated as such.

[nikomatsakis]

@arielb1 I don't disagree with all that. It is certainly intentional that dropck allows access to "potentially dead data" in some cases. The original formulation did not, but we found it was very strict. The goal of the "may observe" relation I was discussing is to specify precisely when it is ok to allow access to potentially dead data, because we can be sure that the data will not be used.

/me kind of misses the days when data with dtors was always Send+'static

[arielb1]

Heh, dtors could always refer to dead types (with unsafe_destructor then).

[nikomatsakis]

@arielb1 yes, they were only ever Send+'static in a fictional dream world :)

[pnkfelix]

okay clearly the Sound Drop RFC needs some updating. The observation that parametricity is not a sufficient condition is important. I will try to incorporate the comments above into a PR on the rfcs repo (either a new RFC or an amendment to Sound Drop, depending on how bad the damage is).

[nikomatsakis]

triage: P-high (soundness issue)