ICE if generic destructor invokes a method on self ("vtables missing where they are needed")

[tychosci]

xyz.rs:

trait X {
    fn call(&self);
}

struct Y;
struct Z<T: X> {
    x: T
}

impl Y: X {
    fn call(&self) {
    }
}

impl<T: X> Z<T>: Drop {
    fn finalize(&self) {
        self.x.call(); // Adding this statement causes an ICE.
    }
}

fn main() {
    let y = Y;
    let _z = Z{x: y};
}

$ RUST_LOG=rustc=1,::rt::backtrace rustc xyz.rs
rust: task failed at 'option::get none', /Users/tychosci/pkg/rust/src/librustc/rustc.rc:1
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
rust: task failed at 'explicit failure', /Users/tychosci/pkg/rust/src/librustc/rustc.rc:425
rust: domain main @0x7feecb000010 root task failed
rust: task failed at 'killed', /Users/tychosci/pkg/rust/src/libcore/task/mod.rs:570

[catamorphism]

Bounds on struct params are no longer supported, so I had to edit a bit, but I still got it to ICE. Will check in the new test case, xfailed. Not critical for 0.6, though, de-milestoning.

[catamorphism]

Still ICEs if I add #[unsafe_destructor]. Nominating for milestone 5, production-ready.

[msullivan]

Still ICEs on this updated test:

trait X {
    fn call(&self);
}

struct Y;
struct Z<T> {
    x: T
}

impl X for Y {
    fn call(&self) {
    }
}

#[unsafe_destructor]
impl<T: X> Drop for Z<T> {
    fn drop(&self) {
        self.x.call(); // Adding this statement causes an ICE.
    }
}

fn main() {
    let y = Y;
    let _z = Z{x: y};
}

It fails because it doesn't have the vtables around... Interesting.

[msullivan]

Ah, so, destructors seem to be generated from a strange codepath such that they never get vtables. See get_res_dtor which calls monomorphic_fn to generate the destructor, and calls it None as the vtables.

[msullivan]

I updated the title on this.

[graydon]

accepted for production-ready milestone

[panzi]

Will this be fixed some when or will it be impossible to write a generic destructor?