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.

Sign up for GitHub

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

Jump to bottom

fix: Normalize projections in evaluated const display and layout calculation #19234

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

fix: Normalize projections in evaluated const display and layout calculation #19234

wants to merge 3 commits into from

Conversation

ChayimFriedman2
Copy link
Contributor

Fixes #19231.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 26, 2025
@ChayimFriedman2 ChayimFriedman2 marked this pull request as draft February 26, 2025 21:46
@ChayimFriedman2
Copy link
Contributor Author

It works with the test but still not working on real IDE for some reason, I'm investigating why.

@ChayimFriedman2 ChayimFriedman2 marked this pull request as ready for review February 27, 2025 12:30
@ChayimFriedman2
Copy link
Contributor Author

OK, this is now ready.

This is a very big PR to fix one FIXME and a tiny issue 🤣

flodiebold
flodiebold approved these changes Feb 27, 2025
View reviewed changes
Copy link
Member

@flodiebold flodiebold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM, though I wonder if we shouldn't have something like a DisplayContext wrapping the CrateId that gets passed everywhere, to 1) make this easier if we need to change again what we need for displaying, 2) make it clearer that this is used for displaying -- I was wondering for a moment why things like EvaluatedConst::render don't just use self.def.krate(), but that's because we're potentially rendering them in a different context.

@ChayimFriedman2
Copy link
Contributor Author

I wonder if we shouldn't have something like a DisplayContext wrapping the CrateId that gets passed everywhere, to 1) make this easier if we need to change again what we need for displaying, 2) make it clearer that this is used for displaying -- I was wondering for a moment why things like EvaluatedConst::render don't just use self.def.krate(), but that's because we're potentially rendering them in a different context.

Yeah I think I'll do that, that sounds like a better idea. I used the name krate because target_crate was too long to type in dozens of places, and still not too clear :)

@ChayimFriedman2
Pass the target crate in HirFormatter
0797a46 
This is required to format evaluated consts, because we need trait env, and it needs the crate (currently it uses the last crate in topological order, which is wrong, the next commit will fix that).
@ChayimFriedman2
Use correct crate for trait env in render_const_scalar()
43e4a5a
@ChayimFriedman2
Copy link
Contributor Author

@flodiebold Okay I implemented that.

flodiebold
flodiebold approved these changes Feb 28, 2025
View reviewed changes
Copy link
Member

@flodiebold flodiebold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@flodiebold flodiebold flodiebold approved these changes

Assignees
No one assigned
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

<layout-error> on u32 bitflags struct
3 participants
@ChayimFriedman2 @flodiebold @rustbot