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.