ICE when using a trait with an associated type as a trait object

[nrc]

#![feature(associated_types)]

trait Foo {
    type A;
}

fn bar(x: &Foo) {}

pub fn main() {
}

[nrc]

cc @nikomatsakis @aturon

The best thing to do here is to use &Foo<A=Baz> (#18432). Is the correct behaviour when using &Foo to treat A as an unbounded type variable or to cause an error because &Foo is not well-specified?

[nrc]

My reading of the RFC is that it should be a compile error to use &Foo - all associated types in an object must be bound in the type (it is unclear from the RFC if having a default type for the associated type means we don't need an equality constraint for that type).

[nrc]

#17732 is very similar, but not quite a dup, the error message here is find_associated_type_in_generics(): no self type (which is wrong - it is not a self type issue).

[aturon]

My reading of the RFC is that it should be a compile error to use &Foo - all associated types in an object must be bound in the type (it is unclear from the RFC if having a default type for the associated type means we don't need an equality constraint for that type).

Yes in general. I think it's fine to allow you to leave it off if there's a default.

[nikomatsakis]

I agree it should be a compile-time error to have an object type for which the values of some associated types are not specified (whether explicitly or via default). However, we have to be careful, because there can be a default that references Self (which is erased). We should catch this and report a nice error. See #18956, which is related.

[nrc]

The ICE is fixed by #19391