remove some potentially unnecessary incompleteness

[lcnr]

I think that's the only incompleteness actually required there (at least for now)?

cc rust-lang/trait-system-refactor-initiative#45

r? @compiler-errors @BoxyUwU

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[lcnr]

from rust-lang/trait-system-refactor-initiative#45

The same pattern also exists for projections. We should probably also prefer those:

trait Trait {
    type Assoc: Into<u32>;
}
impl<T: Into<u32>> Trait for T {
    type Assoc = T;
}
fn prefer_alias_bound<T: Trait>(x: T::Assoc) {
    // There are two possible types for `x`:
    // - `u32` by using the "alias bound" of `<T as Trait>::Assoc`
    // - `<T as Trait>::Assoc`, i.e. `u16`, by using `impl<T> From<T> for T`
    //
    // We infer the type of `x` to be `u32` here as it is highly likely
    // that this is expected by the user.
    let x = x.into();
    println!("{}", std::mem::size_of_val(&x));
}

fn main() {
    prefer_alias_bound::<u16>(0);
}

---

i think we should also strongly prefer alias bound candidates for projections for consistency™, don't have a strong opinion here though.

[lcnr]

this behavior is more incomplete if you have a param env candidate with constraints X and alias bound with constraints Y. want to add a test for this

[compiler-errors]

I think I may prefer us to do this for GATs too, eventually, but this is fine for now. I do appreciate that we're now slightly less incomplete.

r=me with or without test

[bors]

☔ The latest upstream changes (presumably #113393) made this pull request unmergeable. Please resolve the merge conflicts.