GAT ICE: dtorck encountered internal error

[maboesanman]

The issue appeared when following and using the TypeFamily pattern:

Code

#![feature(generic_associated_types)]


pub trait Trait1 {
    type Associated: Ord;
}

pub trait Trait2 {
    type Associated: Clone;
}

pub trait GatTrait {
    type Gat<T: Clone>;
}

pub struct GatStruct;

impl GatTrait for GatStruct {
    type Gat<T: Clone> = Box<T>;
}

pub struct OuterStruct<T1: Trait1, T2: Trait2> {
    inner: InnerStruct<T2, GatStruct>,
    t1:    T1,
}

pub struct InnerStruct<T: Trait2, G: GatTrait> {
    pub gat: G::Gat<T::Associated>,
}

impl<T1, T2> OuterStruct<T1, T2>
where
    T1: Trait1,
    T2: Trait2<Associated = T1::Associated>,
{
    pub fn new() -> Self {
        todo!()
    }
}

Playground link

Meta

rustc --version --verbose:

rustc 1.59.0-nightly (efec54529 2021-12-04)
binary: rustc
commit-hash: efec545293b9263be9edfb283a7aa66350b3acbf
commit-date: 2021-12-04
host: x86_64-apple-darwin
release: 1.59.0-nightly
LLVM version: 13.0.0

Error output

error: internal compiler error: dtorck encountered internal error
  --> src/source.rs:16:26
   |
16 |       pub fn new() -> Self {
   |  __________________________^
17 | |         todo!()
18 | |     }
   | |_____^
   |
   = note: delayed at compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs:67:18

error: internal compiler error: dtorck encountered internal error
  --> src/source.rs:17:9
   |
17 |         todo!()
   |         ^^^^^^^
   |
   = note: delayed at compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs:67:18
   = note: this error: internal compiler error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info)

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:1189:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

Backtrace

error: internal compiler error: dtorck encountered internal error
  --> src/source.rs:16:26
   |
16 |       pub fn new() -> Self {
   |  __________________________^
17 | |         todo!()
18 | |     }
   | |_____^
   |
   = note: delayed at compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs:67:18

error: internal compiler error: dtorck encountered internal error
  --> src/source.rs:17:9
   |
17 |         todo!()
   |         ^^^^^^^
   |
   = note: delayed at compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs:67:18
   = note: this error: internal compiler error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info)

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:1189:13
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display::<&str>
   3: <rustc_errors::HandlerInner>::flush_delayed
   4: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
   5: core::ptr::drop_in_place::<rustc_session::parse::ParseSess>
   6: <alloc::rc::Rc<rustc_session::session::Session> as core::ops::drop::Drop>::drop
   7: core::ptr::drop_in_place::<rustc_interface::interface::Compiler>
   8: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_interface::interface::create_compiler_and_run<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#1}>
   9: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.59.0-nightly (efec54529 2021-12-04) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 -C incremental --crate-type lib

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

query stack during panic:
end of query stack
warning: `cozal` (lib) generated 1 warning
error: could not compile `cozal`; 1 warning emitted

[maboesanman]

playground with the issue

[maboesanman]

additional notes:

adding T1::Associated: Clone to the where for the impl for OuterStruct makes the playground compile. It looks like the compiler should either complain that the associated type is under-specified or implicitly apply the bound.

[jackh726]

So...uh yeah. Something is wrong here. This playground doesn't work: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d4ac99ec4e25ef340002727b453c5d5c

That doesn't use GATs, just normal associated types. The impl definition doesn't error for a missing T1::Associated: Clone bound, but we also can't use that in the new body.

I was scared for a bit that this would be in someway unsound, but it's not.

[jackh726]

Okay, so probably the right solution is to make T1::Associated: Clone be implied here (rather than requiring that bound). I have a POC branch here: https://github.com/jackh726/rust/tree/issue-91985

Unfortunately, it's not as simple as "just make this change". I think either way we run into potential issues. With the above changes, this test passes. But 2 other tests start failing and one has additional errors:

issue-67684.rs goes from pass to fail. We end up with additional obligations, because now we know that A::Error = A::Item, but propagate that A::Item: ParseError (because A::Error: ParseError). Kind of needs the reverse: when we see X: Trait1<Assoc = <Y as Trait2>::Assoc>, we need to also be able to elaborate that any bounds on <Y as Trait2>::Assoc also hold for <X as Trait1>::Assoc.

trait-with-supertraits-needing-sized-self.rs goes from fail to pass. The gist of this is basically when we have something like trait ArithmeticOps: Add<Output=Self> {}, we currently error because Self: Sized doesn't hold. But, with the above branch, we actually imply that Self: Sized holds because Output=Self.

issue-47715.rs ends up with new "type annotations needed" errors. I don't think these errors are correct.

[jackh726]

GATs issue triage: not blocking. From above, this is a more general bug with associated types. Not an backwards-incompatibility hazard.