-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Implement MVP for opaque generic const arguments #150823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
TODO:
|
This comment has been minimized.
This comment has been minimized.
|
When we avoid normalizing type consts to opaque anon consts we need to make sure that the normalization is ambiguous in coherence instead of #![feature(min_generic_const_args, opaque_generic_const_args)]
#[type_const]
const FOO<const N: usize>: usize = const { N + 1 };
#[type_const]
const BAR<const N: usize>: usize = const { N + 1 };
trait Trait {}
impl Trait for [(); FOO::<1>] {}
impl Trait for [(); BAR::<1>] {}ie we don't want this code to pass due to the two opaque anon consts being unequal. |
|
Ooh good point 👍 |
This is meant to be the interim successor to generic const expressions. Essentially, const item RHS's will be allowed to do arbitrary const operations using generics. The limitation is that these const items will be treated opaquely, like ADTs in nominal typing, such that uses of them will only be equal if the same const item is referenced. In other words, two const items with the exact same RHS will not be considered equal. I also added some logic to check feature gates that depend on others being enabled (like oGCA depending on mGCA).
This comment has been minimized.
This comment has been minimized.
|
HIR ty lowering was modified cc @fmease |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| diag.span_note(impl_.self_ty.span, "not a concrete type"); | ||
| } | ||
| } | ||
| if !self.tcx.features().opaque_generic_const_args() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in theory this means we'll suggest the feature gate on stable right? as we use this codepath also for forbidding uses of generic parameters on stable for cases that nameres cant catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it locally to require mgca but forgot to push apparently haha
|
also need to add the coherence test :3 |
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.
I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).
r? @BoxyUwU