-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Allow projections to be used as const generic #104443
Allow projections to be used as const generic #104443
Conversation
This comment has been minimized.
This comment has been minimized.
be960b4
to
1e1f73e
Compare
I moved the normalization outside of the query and added an |
1e1f73e
to
cbbe7ea
Compare
let param_env = ParamEnv::reveal_all().with_reveal_all_normalized(self.tcx); | ||
let node_ty = self.tcx.try_normalize_erasing_regions(param_env, node.ty).unwrap_or(node.ty); |
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.
Both reveal_all
and normalize_erasing_regions
are almost always the wrong thing. Unless you know what it means to use it, you can be sure it's wrong to use it.
The fact that an unnormalized type ends up in a node.ty
is the problem, find out where it comes from and normalize there.
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.
Ah I marked this as resolved mistakenly. Should still check where the node gets its type and normalize there
This comment has been minimized.
This comment has been minimized.
cbbe7ea
to
05ee2ab
Compare
I only cleaned up. I still need to find the root cause of the missing normalization. |
type Identity = Self; | ||
} | ||
|
||
pub fn foo<const X: <i32 as Identity>::Identity>() { |
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.
tbh I am not sure whether i want to insta stabilize projections in const params or keep them as part of the adt_const_params
feature 🤔 needs a lang FCP if insta stable
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.
As you prefer! If a FCP is needed, I'll let someone from your team handle this part.
☔ The latest upstream changes (presumably #104170) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -74,6 +74,11 @@ impl<'tcx> Const<'tcx> { | |||
|
|||
let ty = tcx.type_of(def.def_id_for_type_of()); | |||
|
|||
let param_env = tcx.param_env(def.did); |
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.
This normalization is causing a lot of cycle error. If I nest it into a if TypeVisitable::has_projections(&ty) {
, it reduces greatly the number of such errors but it's not a good solution imo.
Do you have any idea what's going on here? Why would normalization would create cycle errors? (in code like src/test/ui/variance/variance-associated-consts.rs
)
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.
ah yeah ofc that causes issues 😅
having a const parameter in the where clauses now relies on the param_env
query for normalization to get the ty::Const
but we need the ty::Const
as part of the output of the param_env
query.
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.
Any idea how to fix it?
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.
not really 😅 even changing the type of type level constants to not inherit their parents generics won't work because normalization depends on impl headers which can also contain ty::Const
. Normalizing when creating ty::Const
is too early 🤔
If we were to delay normalization of the type of consts to a later point this may mostly work. tbh that makes me think that we shouldn't land this change and should keep forbidding projections in the type of type system constants. Sorry for not noticing this issue earlier 😅 especially as we've had to deal with pretty much the same issue for generic_const_exprs
as well.
05ee2ab
to
00d9f41
Compare
Closing as we can't really do it currently. I added the test in #104717. |
…d-as-const-generic, r=oli-obk Add failing test for projections used as const generic Based on the experiment done in rust-lang#104443, we realized it's currently not possible to support projections in const generics. More information about it in rust-lang#104443 (comment). This PR adds the UI test in any case so we can gather data in order to work towards adding `TyAlias` into the ABI in the future. r? `@oli-obk`
…d-as-const-generic, r=oli-obk Add failing test for projections used as const generic Based on the experiment done in rust-lang#104443, we realized it's currently not possible to support projections in const generics. More information about it in rust-lang#104443 (comment). This PR adds the UI test in any case so we can gather data in order to work towards adding `TyAlias` into the ABI in the future. r? ``@oli-obk``
…d-as-const-generic, r=oli-obk Add failing test for projections used as const generic Based on the experiment done in rust-lang#104443, we realized it's currently not possible to support projections in const generics. More information about it in rust-lang#104443 (comment). This PR adds the UI test in any case so we can gather data in order to work towards adding `TyAlias` into the ABI in the future. r? ```@oli-obk```
Thanks to #103985, we were able to find out about this limitation.
Hopefully, more should follow.
r? @oli-obk