blank specializing impls don't "lock in" defaults

[nikomatsakis]

I believe RFC 2532 changed the behavior so that a "blank impl" effectively "locks in" inherited defaults. This means that, in this code, the () impl "locks in" the associated type value of bool:

#![feature(specialization)]

trait Trait {
    type Assoc;
}

impl<T> Trait for T {
    default type Assoc = bool;
}

impl Trait for () {}

fn foo<X: Trait<Assoc=bool>>() {}

fn main() {
    foo::<u8>(); //~ ERROR
    foo::<()>();
}

However, we currently get two errors (playground):

error[E0271]: type mismatch resolving `<u8 as Trait>::Assoc == bool`
  --> src/main.rs:16:5
   |
13 | fn foo<X: Trait<Assoc=bool>>() {}
   |    ---          ---------- required by this bound in `foo`
...
16 |     foo::<u8>();
   |     ^^^^^^^^^ expected `bool`, found associated type
   |
   = note:         expected type `bool`
           found associated type `<u8 as Trait>::Assoc`
   = note: consider constraining the associated type `<u8 as Trait>::Assoc` to `bool`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html

error[E0271]: type mismatch resolving `<() as Trait>::Assoc == bool`
  --> src/main.rs:17:5
   |
13 | fn foo<X: Trait<Assoc=bool>>() {}
   |    ---          ---------- required by this bound in `foo`
...
17 |     foo::<()>();
   |     ^^^^^^^^^ expected `bool`, found associated type
   |
   = note:         expected type `bool`
           found associated type `<() as Trait>::Assoc`
   = note: consider constraining the associated type `<() as Trait>::Assoc` to `bool`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html

[nikomatsakis]

This was an oversight in #61812 (cc @jonas-schievink -- sorry, I missed this interaction!)

[jonas-schievink]

Seems like this requires somewhat significant changes to the specialization graph – now we don't just need to know the most specialized impl defining the item, but also whether some applicable sub-impl finalizes that definition.

(this was initially induced by #64564, assoc. type defaults aren't required)

[jonas-schievink]

(this was initially induced by #64564, assoc. type defaults aren't required)

I guess that's not quite true – this is always how specialization behaved, but I meant to change this behavior in #64564