-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Clarify which kinds of MIR are allowed during which phases. #94655
Conversation
The new commit adds |
534331f
to
9cdcbbf
Compare
9cdcbbf
to
90810c0
Compare
Added the new phase and renamed the existing phases. @rustbot ready |
@bors r+ Thanks! this is awesome |
📌 Commit 90810c0eabd718ec573878c9bf6d2ffc11896f38 has been approved by |
⌛ Testing commit 90810c0eabd718ec573878c9bf6d2ffc11896f38 with merge 70e77598bd1415c77053c17bb47f6371b0683c66... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
90810c0
to
00938bc
Compare
Yeah, documentation is not one of the tests I usually run locally. New commits switch |
This enhances documentation with these details and extends the validator to check these requirements more thoroughly. As a part of this, we add a new `Deaggregated` phase, and rename other phases so that their names more naturally correspond to what they represent.
00938bc
to
26d7b8d
Compare
@bors r+ |
📌 Commit 26d7b8d has been approved by |
⌛ Testing commit 26d7b8d with merge a566bb2d22e9a17a6090811d09c5d96db02d7bc0... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
oh... we are in beta breakage prevention week already. I guess the best thing would be to wait for beta to branch and then merge this PR. miri can be patched up easily afterwards. Doing it during beta week is hard |
Was that two different unrelated failures? The miri failure and the rustdoc timeout? (how did this even cause the miri failure?) |
hmm.. the miri failure looks like the one in a recent miri update PR. so possibly not related to your PR... maybe we broke miri before beta breakage week and now every PR errors due to that? looking into it, this is indeed not related to this PR |
Clarify which kinds of MIR are allowed during which phases. This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked. There was also some disagreement between the `MirPhase` docs and validator as to what it meant for the `body.phase` field to have a certain value. This PR resolves those disagreements in favor of the `MirPhase` docs (which is what the pass manager implemented), adjusting the validator accordingly. The result is now that the `DropLowering` phase begins with the end of the elaborate drops pass, and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me, but as long as it's documented accurately it should be ok. r? rust-lang/mir-opt
Clarify which kinds of MIR are allowed during which phases. This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked. There was also some disagreement between the `MirPhase` docs and validator as to what it meant for the `body.phase` field to have a certain value. This PR resolves those disagreements in favor of the `MirPhase` docs (which is what the pass manager implemented), adjusting the validator accordingly. The result is now that the `DropLowering` phase begins with the end of the elaborate drops pass, and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me, but as long as it's documented accurately it should be ok. r? rust-lang/mir-opt
@bors r- (till we solve the miri issue ) |
Clarify which kinds of MIR are allowed during which phases. This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked. There was also some disagreement between the `MirPhase` docs and validator as to what it meant for the `body.phase` field to have a certain value. This PR resolves those disagreements in favor of the `MirPhase` docs (which is what the pass manager implemented), adjusting the validator accordingly. The result is now that the `DropLowering` phase begins with the end of the elaborate drops pass, and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me, but as long as it's documented accurately it should be ok. r? rust-lang/mir-opt
Yeah, and the rustdoc timeout seems possibly spurious? Also unsure how I would have caused that |
Rollup of 5 pull requests Successful merges: - rust-lang#94391 (Fix ice when error reporting recursion errors) - rust-lang#94655 (Clarify which kinds of MIR are allowed during which phases.) - rust-lang#95179 (Try to evaluate in try unify and postpone resolution of constants that contain inference variables) - rust-lang#95270 (debuginfo: Fix debuginfo for Box<T> where T is unsized.) - rust-lang#95276 (add diagnostic items for clippy's `trim_split_whitespace`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked.
There was also some disagreement between the
MirPhase
docs and validator as to what it meant for thebody.phase
field to have a certain value. This PR resolves those disagreements in favor of theMirPhase
docs (which is what the pass manager implemented), adjusting the validator accordingly. The result is now that theDropLowering
phase begins with the end of the elaborate drops pass, and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me, but as long as it's documented accurately it should be ok.r? rust-lang/mir-opt