ICE on stable in selection

[syntacticsugarglider]

Ran into an ICE on stable, threw together a quick minimization. There's probably a lot more room here for minimization but some other things I tried mostly wrt switching Debug/format_args! out for something generic weren't immediately successful at reproducing it.

Code

use core::{fmt, marker::PhantomData};

pub trait WrapperTrait {
    type Assoc;
}

pub trait Trait {
    type Assoc;
}

pub struct Ice<T>(<<Dynamic<T> as WrapperTrait>::Assoc as Trait>::Assoc);

impl<T> fmt::Debug for Ice<T>
where
    <<Dynamic<T> as WrapperTrait>::Assoc as Trait>::Assoc: fmt::Debug,
{
    fn fmt(&self, _: &mut fmt::Formatter) -> fmt::Result {
        format_args!("{:?}", self.0);
        todo!()
    }
}

pub struct TraitImplementor;

impl Trait for TraitImplementor {
    type Assoc = ConcreteAssoc;
}

pub struct ConcreteAssoc;

impl<T> WrapperTrait for Dynamic<T> {
    type Assoc = TraitImplementor;
}

pub struct Dynamic<T>(PhantomData<T>);

Meta

rustc --version --verbose:

rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: x86_64-unknown-linux-gnu
release: 1.55.0
LLVM version: 12.0.1

Error output

warning: Error finalizing incremental compilation session directory `<local working dir elided>/target/debug/incremental/ice_repro-2wh62tfxoond5/s-g39h6fbohq-1vpmobs-working`: No such file or directory (os error 2)

error: internal compiler error: Encountered error `Unimplemented` selecting `Binder(<ConcreteAssoc as std::fmt::Debug>, [])` during codegen
  |
  = note: delayed at compiler/rustc_trait_selection/src/traits/codegen.rs:68:32

Backtrace

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:1050:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:515:5
   1: std::panicking::begin_panic_fmt
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:457:5
   2: rustc_errors::HandlerInner::flush_delayed
   3: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
   4: core::ptr::drop_in_place<rustc_session::parse::ParseSess>
   5: <alloc::rc::Rc<T> as core::ops::drop::Drop>::drop
   6: core::ptr::drop_in_place<rustc_interface::interface::Compiler>
   7: rustc_span::with_source_map
   8: rustc_interface::interface::create_compiler_and_run
   9: scoped_tls::ScopedKey<T>::set

[syntacticsugarglider]

playground link

[jackh726]

If I had to guess, this is because in the non-codegen phase, we can't prove <<Dynamic<T> as WrapperTrait>::Assoc as Trait>::Assoc: fmt::Debug, because we're generic over T, but later on during codegen phase, we try to normalize that, see that there's only one applicable impl for WrapperTrait for Dynamic<T>, pick that, then find that ConcreteAssoc: Debug doesn't hold. But by this point we're "too late" and already doing codegen.

Seems like a very lazy-norm thing and this is all speculation.

[Alexendoo]

#90891 changed the format_args expansion slightly so the example no longer ICEs, but it can still be reproduced by calling ArgumentV1::new manually

#![feature(fmt_internals)]

use core::{fmt, marker::PhantomData};

pub trait WrapperTrait {
    type Assoc;
}

pub trait Trait {
    type Assoc;
}

pub struct Ice<T>(<<Dynamic<T> as WrapperTrait>::Assoc as Trait>::Assoc);

fn ice<T>(i: Ice<T>)
where
    <<Dynamic<T> as WrapperTrait>::Assoc as Trait>::Assoc: fmt::Debug,
{
    fmt::ArgumentV1::new(&i.0, fmt::Debug::fmt);
}

pub struct TraitImplementor;

impl Trait for TraitImplementor {
    type Assoc = ConcreteAssoc;
}

pub struct ConcreteAssoc;

impl<T> WrapperTrait for Dynamic<T> {
    type Assoc = TraitImplementor;
}

pub struct Dynamic<T>(PhantomData<T>);

[oli-obk]

Hmm... this is what I was worried about in the PR. This compiles now, but the trait bound ConcreteAssoc::Debug doesn't hold.

[cjgillot]

Is it an issue? The function ice is never called, so no code ever has to prove this bound.

[oli-obk]

oh 🤦 yea, I can't find a way to call it either. Thanks!

[oli-obk]

This is fixes and we have appropriate tests imo