It is possible to call object member function after object had been dropped

[yegor-alexeyev]

Please look at gist https://gist.github.com/yegor-alexeyev/9152969
If execute, "drop" would be printed before the value of memory of dropped object

[huonw]

Thanks for the report... this is definitely a problem.

I'll reproduce the code here (slightly modified), just so that we're not depending on that gist being permanent:

trait X {
    fn get_i(&self) -> int;
}


struct B {
    i: int
}

impl X for B {
    fn get_i(&self) -> int {
        self.i
    }
}

impl Drop for B {
    fn drop(&mut self) {
        println!("drop");
    }
}

struct A<'r> {
    p: &'r X
}

fn make_a<'r>(p:&'r X) -> A<'r> {
    A{p:p}
}

fn make_make_a() -> A {
    let b: ~B = ~B {i:1};
    let bb: & B = b;
    make_a(bb)
}

fn main() {
    let a = make_make_a();
    println!("{}", a.p.get_i());
}

which prints

drop
0

with the latest master.

Also, this seems very similar to #11374, since any attempt to remove the trait or the trait object makes the code stop compiling.

[alexcrichton]

Nominating.

[dmski]

I'd like to (try to) fix this.
Also #5723, #11374, #11971 and #12781 all seem related.

[brson]

@dmski Go for it!

[pnkfelix]

Assigning 1.0, P-backcompat-lang.

[dmski]

PR #12828 might also be related: it would seem that A is considered bivariant and free region constraint doesn't get added to A{p:p} as a result:
sub.tys(A<>, A<>) super_tys: a_sty=&ty_struct(syntax::ast::DefId{krate: 0u32, node: 81u32}, middle::ty::substs{self_ty: None, tps: std::vec_ng::Vec<middle::ty::t>{len: 0u, cap: 0u, ptr: (0x0 as *mut ())}, regions: NonerasedRegions(Vec(std::vec_ng::Vec<middle::ty::Region>{len: 1u, cap: 1u, ptr: (0x7fd17a54c140 as *mut ())}))}) b_sty=&ty_struct(syntax::ast::DefId{krate: 0u32, node: 81u32}, middle::ty::substs{self_ty: None, tps: std::vec_ng::Vec<middle::ty::t>{len: 0u, cap: 0u, ptr: (0x0 as *mut ())}, regions: NonerasedRegions(Vec(std::vec_ng::Vec<middle::ty::Region>{len: 1u, cap: 1u, ptr: (0x7fd17a54c110 as *mut ())}))}) relate_region_params(item_def_id=syntax::ast::DefId{krate: 0u32, node: 81u32}:A, a_rs=[ReInfer(1)], b_rs=[ReFree(105, BrAnon(0))], region_params=[*]) success

But if A is defined as
struct A<'r> { p: &'r B }
Then A is considered contravariant and region for A{p:p} gets considered free.

[edwardw]

With the latest #12828, rustc now rejects the code:

...
fn make_make_a() -> A {
    let b: ~B = ~B {i:1};
    let bb: & B = b;  // error: `*b` does not live long enough
    make_a(bb)
}
...

But of course, the fix is meant to implement RFC for tweaked variance inference rules, which itself is still in flux.

[dmski]

Am i right in thinking that the fix for trait contravariance (i.e. edwardw@4c51634) is relatively independent of what RFC and #12828 originally tried to do, and so can be split off? That fix alone corrects this issue (though also leads to an error compiling json.rs).

[edwardw]

Yes, the fixing ty_trait part is just a bug fix, prelude to the tweaked variance inference RFC if you will.

[nrc]

I have sort of fixed this in my branch (PR coming soon). My branch forces lifetimes to be invariant, but still allows bounds to be covariant (the latter was to hard to address fix instances of in the compiler, or at least was potentially open-ended enough to put me off trying). I have left a FIXME pointing to this issue in the code for the covariance fix, it would only require removing a small hack. Tidying up afterwards may or may not be an issue.

The test case above gives the following error:

assign.rs:32:19: 32:20 error: `*b` does not live long enough
assign.rs:32     let bb: & B = b;
                               ^
assign.rs:30:23: 34:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 30:22...
assign.rs:30 fn make_make_a() -> A {
assign.rs:31     let b: Box<B> = box B {i:1};
assign.rs:32     let bb: & B = b;
assign.rs:33     make_a(bb)
assign.rs:34 }
assign.rs:30:23: 34:2 note: ...but borrowed value is only valid for the block at 30:22
assign.rs:30 fn make_make_a() -> A {
assign.rs:31     let b: Box<B> = box B {i:1};
assign.rs:32     let bb: & B = b;
assign.rs:33     make_a(bb)
assign.rs:34 }

We should add a proper test here before this issue can be considered closed.