Soundness hole: We don't catch non-const assoc fns in const contexts if the trait isn't #[const_trait]

[fmease]

Uplifted from rust-lang/rust#125831 cuz I consider this pretty important.

MCVE:

//@ compile-flags: -Znext-solver
#![feature(effects, const_trait_impl)]
#![crate_type = "lib"]

// #[const_trait] // <-- intentionally absent
trait NonConstTrait {
    fn something();
}

impl NonConstTrait for () {
    fn something() {}
}

const fn f() { <()>::something() } // wrongfully accepted!
                                   // should've raised Unimplemented( (): ~const NonConstTrait )
                                   // or at least rejected this call some other way

[fmease]

So I haven't dug into details yet as to why it slips up but from a high-level perspective "things" may "generate" Ty: ~const NonConstTrait obligations/goals even if ~const NonConstTrait is ill-formed in the surface language (~const can only be applied to #[const_trait] traits).

[compiler-errors]

This should be fixed when we rework how we validate const traits in MIR, i.e. this code is currently busted:

https://github.com/rust-lang/rust/blob/45089ec19ebebec88bace6ec237244ff0eaa7ad3/compiler/rustc_const_eval/src/check_consts/check.rs#L607-L627

And/or when we start unconditionally enforcing constness in HIR:

https://github.com/rust-lang/rust/blob/45089ec19ebebec88bace6ec237244ff0eaa7ad3/compiler/rustc_hir_typeck/src/callee.rs#L876-L877

[compiler-errors]

I'm currently working on improving const validation in MIR, though, so I'll claim this as a placeholder. Thanks for raising this issue, tho.