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?

[thestinger]

This bug is quite hard to fix. The typeck part of compilation outputs the necessary vtable information based on the context of method calls. Since destructor calls are not part of the AST, there is no metadata generated for them so there's nothing for the get_res_dtor function to ask for.

[pnkfelix]

Its pretty hard to trace back from the ICE's that one gets to this cause. E.g. messages like this (see #8286):

task 'rustc' failed at 'vtables missing where they are needed', 
   /Users/rustbuild/src/rust-buildbot/slave/snap3-mac/build/src/libstd/option.rs:111

do not tell the user that they should revise the code of their destructor. (Admittedly, generic destructors are already unsafe ... but to me, unsafe does not imply "may cause the compiler to ICE" -- just the generated code!)

We should either figure out a way to allow generic destructors to invoke methods on self, or we should emit an error or warning earlier on in the compilation so that someone has a prayer of dissecting this problem without hunting through our issue database.

Nominating for 1.0, P-backcompat-lang.

[pnkfelix]

Definitely something we should resolve one way or another for 1.0, even if its just about getting the error message better (but ideally, since RAII is part of our story, we'd do better than that.)

P-high