ICE on unsound usage of existential types

[CryZe]

You can construct an existential type that implements traits that it shouldn't have like so:

#![feature(existential_type)]

existential type Foo<T>: Default;

#[allow(unused)]
fn foo<T: Default>(t: T) -> Foo<T> {
    t
}

struct NotDefault;

fn main() {
    let _ = Foo::<NotDefault>::default();
}

Playground

As you can see Foo's type parameter T doesn't have a Default bound, but it still implements the Default trait as a whole. If you actually abuse this with a type parameter that doesn't implement Default, you can construct a value even though the type doesn't implement Default. This results in an ICE atm:

$ cargo +nightly run
   Compiling unsound-existentials v0.1.0 (file:///C:/Projekte/one-offs/unsound-existentials)
error: internal compiler error: librustc\traits\codegen\mod.rs:68: Encountered error `Unimplemented` selecting `Binder(<NotDefault as std::default::Default>)` during codegen

thread 'main' panicked at 'Box<Any>', librustc_errors\lib.rs:578:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error


note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.29.0-nightly (866a71325 2018-07-29) running on x86_64-pc-windows-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `unsound-existentials`.

To learn more, run the command again with --verbose.

This may just be an unimplemented check due to existential types being brand new on nightly.

[oli-obk]

foo should not be a defining use for Foo, because its bindings differ.

[JohnTitor]

Doesn't reproduce in the latest nightly

[JohnTitor]

Ah, wait, the latest example is here, this is still ICE.