Assoc const equality bounds aren't taken into consideration when normalizing const projections

[fmease]

For example, I expected the following code to succeed compilation:

#![feature(generic_const_exprs)]
#![feature(associated_const_equality)]

trait Trait {
    const C: usize;
}

fn f<T: Trait<C = 1>>()
where
    [(); T::C]:
{
    let _: [(); T::C] = [()];
}

Since (I'm pretty sure that) the ParamEnv contains the projection predicate <T as Trait>::C == 1, the const projection <T as Trait>::C inside the function body should be able to get normalized to 1. That however doesn't seem to happen:

error[E0308]: mismatched types
  --> src/lib.rs:12:25
   |
12 |     let _: [(); T::C] = [()];
   |                         ^^^^ expected `T::C`, found `1`
   |
   = note: expected constant `T::C`
              found constant `1`

[fmease]

TODO: Find a reproducer that isn't reliant on GCE. Reliance on mGCE/mGCA (min_generic_const_args) is fine on the other hand (once that's implemented).

[fmease]

After poking around some more, I've come to the same conclusion that this requires extending the normalization rules of UnevaluatedConst (const projections).

Like, rustc_trait_selection::traits::try_evaluate_const which is the entry point we're interested in I think doesn't do much except deferring "overly generic" const projects (where are those ultimately solved though? I couldn't find that out (try_evaluated_const again?)) or delegating normalization to the const evaluation machinery.

I presume what we would want to assemble some other candidates in try_evaluate_const (?) like we do for type projections. Most importantly ParamEnv candidates (cf. rustc_trait_selection::traits::project::assemble_candidates_from_param_env) and perform some sort of selection. Nothing feels like the right place though but that's likely because I don't know enough yet. Esp. due to the const projection deferral. I don't want to touch anything rn because this is GCE→(m)GCA territory and maybe also next-solver territory (in the sense that we likely want to implement that in the next solver only because doing so in the old solver (too) would be wasted effort and overly complex and fragile).