Inconsistent handling of associated constants in patterns

[sportzer]

The following code compiles:

trait Foo {
    const C: i32;
}

impl<T> Foo for T {
    const C: i32 = 0;
}

fn bar<T>() {
    match 0 {
        <T as Foo>::C => (),
        _ => (),
    }
}

but adding a trait bound of Foo to bar:

trait Foo {
    const C: i32;
}

impl<T> Foo for T {
    const C: i32 = 0;
}

fn bar<T: Foo>() {
    match 0 {
        <T as Foo>::C => (),
        _ => (),
    }
}

causes compilation to fail with:

error[E0158]: associated consts cannot be referenced in patterns
  --> src/main.rs:14:9
   |
14 |         <T as Foo>::C => (),
   |         ^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0158`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

I would expect these two cases to behave identically instead of one working and the other failing. (it seems like both cases should be disallowed, but I don't have a good grasp of the current state of relevant features)

This is reproducible in the rust playground on the stable, beta, and nightly channels

[fmease]

Marking A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) because const_eval_resolve_for_typeck returns TooGeneric here in unevaluated_to_pat but ultimately it's a T-types / A-trait-system question. I haven't thought much about this issue, so maybe it's pretty obvious why we fail to normalize here but anyway I presume the difference is CandidateSource::Impl vs. CandidateSource::ParamEnv (the latter shadowing the former even though the obligation/goal could be normalized "immediately" via the user-impl candidate, cc: #24066 maybe) and therefore the const projection (UnevaluatedConst) is considered / stays rigid → TooGeneric. Just a hunch.