Normalize consts in writeback when GCE is enabled #130645
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 21, 2024
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129718 (add guarantee about remove_dir and remove_file error kinds) - rust-lang#130598 (Add recursion limit to FFI safety lint) - rust-lang#130642 (Pass the current cargo to `run-make` tests) - rust-lang#130644 (Only expect valtree consts in codegen) - rust-lang#130645 (Normalize consts in writeback when GCE is enabled) - rust-lang#130646 (compiler: factor out `OVERFLOWING_LITERALS` impl) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 21, 2024
Rollup merge of rust-lang#130645 - compiler-errors:normalize-gce-writeback, r=BoxyUwU Normalize consts in writeback when GCE is enabled GCE lazily normalizes its unevaluated consts. This PR ensures that, like the new solver with its lazy norm types, we can assume that the writeback results are fully normalized. This is important since we're trying to eliminate unnecessary calls to `ty::Const::{eval,normalize}` since they won't work with mGCE. Previously, we'd keep those consts unnormalized in writeback all the way through MIR build, and they'd only get normalized if we explicitly called `ty::Const::{eval,normalize}`, or during codegen since that calls `normalize_erasing_regions` (which invokes the `QueryNormalizer`, which evaluates the const accordingly). This hack can (hopefully obviously) be removed when mGCE is implemented and we yeet the old GCE; it's only reachable with the GCE flag anyways, so I'm not worried about the implications here. r? `@BoxyUwU`
This was referenced Sep 22, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 22, 2024
…al, r=BoxyUwU
Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis
We normalize consts in writeback: rust-lang#130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`.
Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
r? `@BoxyUwU`
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Sep 23, 2024
…al, r=BoxyUwU
Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis
We normalize consts in writeback: rust-lang#130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`.
Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 23, 2024
…al, r=BoxyUwU
Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis
We normalize consts in writeback: rust-lang#130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`.
Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 23, 2024
Rollup merge of rust-lang#130715 - compiler-errors:mir-build-const-eval, r=BoxyUwU Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis We normalize consts in writeback: rust-lang#130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`. Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GCE lazily normalizes its unevaluated consts. This PR ensures that, like the new solver with its lazy norm types, we can assume that the writeback results are fully normalized.
This is important since we're trying to eliminate unnecessary calls to
ty::Const::{eval,normalize}since they won't work with mGCE. Previously, we'd keep those consts unnormalized in writeback all the way through MIR build, and they'd only get normalized if we explicitly calledty::Const::{eval,normalize}, or during codegen since that callsnormalize_erasing_regions(which invokes theQueryNormalizer, which evaluates the const accordingly).This hack can (hopefully obviously) be removed when mGCE is implemented and we yeet the old GCE; it's only reachable with the GCE flag anyways, so I'm not worried about the implications here.
r? @BoxyUwU