Repository navigation
trait method calls on ~const bounded types should not be allowed in generic const exprs #102498
Description
#![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.
Activity
oli-obk commentedon Sep 30, 2022
I think this issue is a good use case for a
// known-bugissue until we fix it (may be automatically fixed by keyword generics)Add a known-bug test for rust-lang#102498
Rollup merge of rust-lang#102566 - compiler-errors:test-102498, r=Mar…
Rollup merge of rust-lang#102566 - compiler-errors:test-102498, r=Mar…
Rollup merge of rust-lang#102566 - compiler-errors:test-102498, r=Mar…
Auto merge of rust-lang#102586 - Dylan-DPC:rollup-g107h6z, r=Dylan-DPC
Auto merge of rust-lang#102586 - Dylan-DPC:rollup-g107h6z, r=Dylan-DPC
juntyr commentedon Dec 8, 2023
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 commentedon Feb 12, 2025
Under the current implementation this gets rejected with and without
huhexisting1, 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,
foois only legal if you swap the conditionally-const with an always-const bound.Footnotes
Obviously after having added
#[const_trait]toTr. ↩