trait method calls on ~const bounded types should not be allowed in generic const exprs

[fee1-dead]

playground

#![feature(const_trait_impl, generic_const_exprs)]

#[const_trait]
pub trait Tr {
    fn a() -> usize;
}

impl Tr for () {
    fn a() -> usize {
        1
    }
}

const fn foo<T: ~const Tr>() -> [u8; T::a()] {
    [0; T::a()]
}

fn huh() {
    foo::<()>();
}

If we remove the huh definition, it compiles. This fix would involve treating caller bounds differently and would probably come with the addition of "always const" bounds.

This is an interaction with generic_const_exprs and const_trait_impl, but does not block the stabilization of generic_const_exprs as this is only allowed if someone enables the feature const_trait_impl.

[oli-obk]

I think this issue is a good use case for a // known-bug issue until we fix it (may be automatically fixed by keyword generics)

[juntyr]

I stumbled across this case today - is there a way yet in the const-trait-rewrite to use const-if-const trait methods inside constants? Is one planned (before the rewrite started, this case was supported) or will this require new always-const bounds?

[fmease]

Under the current implementation this gets rejected with and without huh existing¹, so this is … fixed if I understand correctly? I don't believe this needs a regression test since I'm pretty sure we already have some that cover ~this.

Like, foo is only legal if you swap the conditionally-const with an always-const bound.

Footnotes

1. Obviously after having added #[const_trait] to Tr. ↩