Skip to content

Should we be eagerly evaluating consts in the "old"-style normalizer? #28

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

Closed
compiler-errors opened this issue Jun 1, 2023 · 1 comment

Comments

@compiler-errors
Copy link
Member

compiler-errors commented Jun 1, 2023

Right now, the AssocTypeFolder will eagerly evaluate consts unless GCE is enabled. We still have usages of this folder (the "old"-style normalizer) all over the place, and tearing that out is a lot of work.

Eventually, I'd like to move away from normalizing types or consts unless there's a clear reason for the normalization (i.e. we structurally normalize types in HIR typeck for various reasons like field acceses).

Right now we continue to eagerly normalize types in HIR typeck. Doing this for consts and not for types does introduce an incongruency that may make subtle alias-relate bugs appear just for consts, but it does get us one step closer to always-lazy-norm...

rust-lang/rust#112183 (comment)

@lcnr
Copy link
Contributor

lcnr commented Jan 29, 2025

We normalize constants in all places which normalizes types and expect it to stay that way. I feel confident in our current normalization approach and don't expect us to cause const and ty normalization to diverge.

I don't think this issue is useful to track anything because of that. Even if normalizing consts will cause issues, I don't think keeping this issue open is valuable for that.

@lcnr lcnr closed this as completed Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants