ICE with class in polymorphic impl function in crate

[bblum]

x.rs:

enum x = (); 
impl x for x { 
    fn use_x<T>() {
        struct foo {
            i: (); 
            new(i: ()) { self.i = i; }
        }   
    }   
}

x.rc:

#[crate_type = "lib"];

The code works if:

• it is not polymorphic.
• the struct is moved outside of the impl, or the impl is removed and the struct is inside the function.
• a fn main is added and compiled as not-a-crate.
• a fn main is added and compiled as a crate but the #[crate_type = "lib"] is removed.

It still ICEs if the type parameter is moved up to impl x<T> for x .

Backtrace:

#1  0x00007ffff66d2087 in diagnostic::codemap_handler::meth541::fatal ()
#2  0x00007ffff66d23fb in diagnostic::codemap_handler::meth551::bug ()
#3  0x00007ffff6069b23 in metadata::encoder::encode_symbol ()
#4  0x00007ffff606cc62 in metadata::encoder::encode_info_for_fn ()
#5  0x00007ffff60728de in metadata::encoder::encode_info_for_items::anon ()
#6  0x00007ffff5cc684a in visit::visit_block6832 ()
#7  0x00007ffff5ccdc44 in visit::visit_fn7049 ()
#8  0x00007ffff5ccce7a in visit::visit_method_helper7014 ()
#9  0x00007ffff5cccca2 in visit::visit_item7001 ()
#10 0x00007ffff606f22c in metadata::encoder::encode_info_for_items::anon ()
#11 0x00007ffff60d09b0 in __morestack ()
#12 0x00007ffff5ccc474 in visit::default_visitor6990::anon ()
#13 0x00007ffff5d02949 in metadata::encoder::encode_metadata ()
#14 0x00007ffff5cfe4d1 in middle::trans::base::write_metadata ()

Possibly related to #2733.

[bblum]

I had to work around this here: f2ca549#L1R94

[catamorphism]

This doesn't typecheck now, because x isn't a trait. Do you have another program that does implement a trait, but shows the same bug?

[bblum]

Um, it lets me write a non-trait impl as long as the type is owned by the module, which is what enum x is for. All the code in std::sync and std::arc is like this...

But here's a more traitorous version:

trait x {
    fn use_x<T>();
}
enum y = (); 
impl y:x { 
    fn use_x<T>() {
        struct foo {
            i: (); 
            new(i: ()) { self.i = i; }
        }   
    }   
}

[catamorphism]

This appears to be fixed as of a477c5a, though I had to rewrite it to not use an old-style constructor. Perhaps that's the reason. In any case, I'll check in a test case once the tree reopens.