ICE if generic destructor has several type parameters

[bluss]

A generic destructor with more than one type parameter (one more than the struct in this case), causes an ICE. A bound like <T: Iterator<T>> (for example) compiles, while <A, T: Iterator<A>> does not.

#![feature(unsafe_destructor)]
struct Test<T>(T);

#[unsafe_destructor]
impl <A, T: Iterator<A>> Drop for Test<T> {
    fn drop(&mut self) {  }
}

fn main() {
    let x = Test(2i);
    let _ = x;
}

ICE:

error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'index out of bounds: the len is 1 but the index is 1', /build/rust-git/src/rust/src/librustc/middle/subst.rs:420

See also previous issue #4252 and its fix #12403

31 aug 2014: updated test code to compile with current rust, and updated to new different ICE msg.

[Dr-Emann]

I get a similar ICE under slightly different conditions:

struct MyType<T> { v: T }
#[unsafe_destructor]
impl Drop for MyType<u8> {
    fn drop(&mut self) { () }
}

fn main() {
    MyType{v:3u}
}

The error occurs whether drop is defined for that version of MyType or not. (u8, or otherwise in this case)
The error is not thrown if the type is never instantiated. There is no complaint with declaring such a struct and destructor.

ICE

error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'assertion failed: `(left == right) && (right == left)` (left: `1`, right: `0`)', /build/buildd/rust-nightly-201406100407~907d961~trusty/src/librustc/middle/typeck/check/vtable.rs:90


make: *** [target/x86_64-unknown-linux-gnu/lib/libirc-ad3d5237-0.1.rlib] Error 101

[Twisol]

Neither example currently causes an ICE, though some modernization changes needed to be made:

Original example (modified for associated types in Iterator):

$ rustc foo.rs
$ cat foo.rs
#![feature(unsafe_destructor)]
struct Test<T>(T);

#[unsafe_destructor]
impl <T: Iterator> Drop for Test<T> {
    fn drop(&mut self) {  }
}

fn main() {
    let x = Test(2i);
    let _ = x;
}

Second example (modified so main returns ()):

$ rustc foo.rs
foo.rs:3:20: 3:24 warning: struct field is never used: `v`, #[warn(dead_code)] on by default
foo.rs:3 struct MyType<T> { v: T }
                            ^~~~
$ cat foo.rs
#![feature(unsafe_destructor)]
struct MyType<T> { v: T }

#[unsafe_destructor]
impl Drop for MyType<u8> {
    fn drop(&mut self) { () }
}

fn main() {
    let _foo = MyType{v:3u};
}

Version:

$ rustc --verbose --version
rustc 0.13.0-nightly (c6c786671 2015-01-04 00:50:59 +0000)
binary: rustc
commit-hash: c6c786671d692d7b13c2e5c68a53001327b4b125
commit-date: 2015-01-04 00:50:59 +0000
host: x86_64-apple-darwin
release: 0.13.0-nightly

[steveklabnik]

The first example does ICE for me:

#![feature(unsafe_destructor)]
struct Test<T>(T);

#[unsafe_destructor]
impl <A, T: Iterator<Item=A>> Drop for Test<T> {
    fn drop(&mut self) {  }
}

fn main() {
    let x = Test(2i);
    let _ = x;
}

[tamird]

#![feature(unsafe_destructor)]

struct Test<T>(T);

#[unsafe_destructor]
impl <A, T:Iterator <Item = A>> Drop for Test<T> {
  fn drop(&mut self) {}
}

fn main() {
  Test(2);
}

Still ICEs as of 95018ee.

[pnkfelix]

This is at least somewhat related to #8142, since this is an instance of a "specialized drop" where the Drop impl has bounds on T that are not present in the struct definition for struct Test<T> itself.

This variant has a proper compiler error message:

#![feature(unsafe_destructor)]

struct Test<T:Iterator>(T);

#[unsafe_destructor]
impl <A, T:Iterator<Item=A>> Drop for Test<T> {
  fn drop(&mut self) {}
}

fn main() {
  Test(2);
}

[tamird]

None of these examples ICE today. I think this was fixed by #23638.

@steveklabnik close?

[pnkfelix]

@tamird I think at this point we just want to add regression tests (and/or at least check that all of the examples given here are reasonably covered by the existing test suite).

[tamird]

@pnkfelix I think your tests at https://github.com/rust-lang/rust/blob/master/src/test/compile-fail/reject-specialized-drops-8142.rs cover this.

[pnkfelix]

@tamird While I'd love for that to be true, skimming over that test suite, I do not see any tests of parameter bounds that use the associated-item constraint syntax like <A, T: Iterator<Item=A>>. So there may still be room for improved testing here.

[bluss]

The issue was probably due to a configuration that can't be reached today -- Drop with two type parameters and struct with just one. The following compiles on nightly

struct Test<A, T: Iterator<Item=A>>(T);

impl <A, T: Iterator<Item=A>> Drop for Test<A, T> {
    fn drop(&mut self) {  }
}

fn main() {
    let x = Test(2..);
    let _ = x;
}

[steveklabnik]

Seems good then 👍