Permit trait object types where all (non-generic) associated constants are specified (via assoc item bindings)

[fmease]

Important context: Inherently, this would only become legal under the ongoing lang experiment associated_const_equality (#92827).

We permit trait object types where all 'active'¹ non-generic associated types are specified (via assoc item bindings). We should extend this to cover 'active' non-generic² associated constants, too.

Note that I haven't spent much time thinking about soundness yet. I still need to iron out the exact rules. Implementation-wise, I'm almost certain that any advances are blocked by #120905 (more precisely, its underlying issue) which I presume we would need to fix first for correctness.

Minimal & contrived example of something that would start compiling:

#![feature(associated_const_equality)]

trait Trait {
    const K: ();
}

fn main() {
    let _: dyn Trait<K = { () }>;
}

Presently, this gets rejected and we emit E0038 (cannot be made into an object).

---

Lastly, lest I forget, we should emit the lint unused_associated_type_bounds³ (#112319) for assoc const bindings where the corresp. assoc const is 'disabled' via where Self: Sized which is only possible to write under generic_const_items (#113521).

---

Footnotes

1. I.e., not 'made inactive' / 'disabled' via where Self: Sized (Don't require associated types with Self: Sized bounds in dyn Trait objects #112319). ↩

2. This might or might not be a temporary restriction. For context, we don't (yet) permit GAT bindings in trait object types either on stable, due to soundness concerns. See generic_associated_types_extended (Tracking Issue for extended generic associated types #95451). Also note that generic assoc consts (GACs) are only available under generic_const_items (Tracking issue for generic const items #113521). ↩

3. Indeed, the name would no longer be accurate. Ideally, we would rename the lint when generalizing it. ↩

[fmease]

After poking around some more, I've come to the same conclusion that this is blocked on extending the normalization rules of UnevaluatedConst (const projections) (see also #120905).

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).

This all seems relevant to "ACE in dyn" because lifting the dyn compatibility restrictions around assoc consts just lead to another dyn incompatibility: Given trait Tr { const N: usize; fn check(&self, _: [(); Self::N]); }, the trait ref Tr<N = 1> remains dyn incompatible because presumably [(); Self::N] doesn't normalize to [(); 1] leading to an illegal Self ty param remaining.