Skip to content
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

Conversation

GuillaumeGomez
Copy link
Member

Thanks to #103985, we were able to find out about this limitation.

Hopefully, more should follow.

r? @oli-obk

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 15, 2022
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez GuillaumeGomez force-pushed the projection-as-const-generic branch 2 times, most recently from be960b4 to 1e1f73e Compare November 16, 2022 10:43
@GuillaumeGomez
Copy link
Member Author

I moved the normalization outside of the query and added an assert to ensure it's always called on normalized items.

src/test/ui/const-generics/projection-as-arg-const.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/projection-as-arg-const.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/projection-as-arg-const.rs Outdated Show resolved Hide resolved
Comment on lines +225 to +226
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);
Copy link
Contributor

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.

Copy link
Contributor

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

compiler/rustc_middle/src/ty/consts.rs Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez
Copy link
Member Author

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>() {
Copy link
Contributor

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

Copy link
Member Author

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.

@bors
Copy link
Contributor

bors commented Nov 17, 2022

☔ The latest upstream changes (presumably #104170) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk oli-obk added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 17, 2022
@@ -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);
Copy link
Member Author

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)

Copy link
Contributor

@lcnr lcnr Nov 22, 2022

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.

Copy link
Member Author

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?

Copy link
Contributor

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.

@GuillaumeGomez
Copy link
Member Author

Closing as we can't really do it currently. I added the test in #104717.

@GuillaumeGomez GuillaumeGomez deleted the projection-as-const-generic branch November 22, 2022 15:06
Manishearth added a commit to Manishearth/rust that referenced this pull request Nov 22, 2022
…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`
JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Nov 22, 2022
…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``
Manishearth added a commit to Manishearth/rust that referenced this pull request Nov 22, 2022
…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```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants