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

Clarify which kinds of MIR are allowed during which phases. #94655

Merged
merged 2 commits into from
Mar 25, 2022

Conversation

JakobDegen
Copy link
Contributor

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

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 6, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 6, 2022
@JakobDegen
Copy link
Contributor Author

JakobDegen commented Mar 6, 2022

The new commit adds an two unrelated documentation improvements that I wanted to tack onto some PR

@oli-obk oli-obk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2022
@JakobDegen
Copy link
Contributor Author

Added the new phase and renamed the existing phases.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 17, 2022
@oli-obk
Copy link
Contributor

oli-obk commented Mar 23, 2022

@bors r+

Thanks! this is awesome

@bors
Copy link
Contributor

bors commented Mar 23, 2022

📌 Commit 90810c0eabd718ec573878c9bf6d2ffc11896f38 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 23, 2022
@bors
Copy link
Contributor

bors commented Mar 23, 2022

⌛ Testing commit 90810c0eabd718ec573878c9bf6d2ffc11896f38 with merge 70e77598bd1415c77053c17bb47f6371b0683c66...

@bors
Copy link
Contributor

bors commented Mar 23, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 23, 2022
@rust-log-analyzer

This comment has been minimized.

@JakobDegen
Copy link
Contributor Author

Yeah, documentation is not one of the tests I usually run locally. New commits switch Terminator out for TerminatorKind

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.
@oli-obk
Copy link
Contributor

oli-obk commented Mar 24, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Mar 24, 2022

📌 Commit 26d7b8d has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 24, 2022
@bors
Copy link
Contributor

bors commented Mar 24, 2022

⌛ Testing commit 26d7b8d with merge a566bb2d22e9a17a6090811d09c5d96db02d7bc0...

@bors
Copy link
Contributor

bors commented Mar 24, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 24, 2022
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: 1 unexpected errors found, 1 expected errors not found
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools-bin/miri" "tests/compile-fail/null_pointer_deref.rs" "-L" "/tmp/compiletestSKklR3" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/compiletestSKklR3/null_pointer_deref.stage-id" "-A" "unused" "--edition" "2018" "-Astable-features" "--sysroot" "/home/user/.cache/miri/HOST" "-L" "/tmp/compiletestSKklR3/null_pointer_deref.stage-id.aux"
    Error {
        line_num: 3,
        kind: Some(
            Error,
---
error: tests/compile-fail/null_pointer_write.rs:3: expected error not found: null pointer is not a valid pointer for this operation

error: 1 unexpected errors found, 1 expected errors not found
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools-bin/miri" "tests/compile-fail/null_pointer_write.rs" "-L" "/tmp/compiletestSKklR3" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/compiletestSKklR3/null_pointer_write.stage-id" "-A" "unused" "--edition" "2018" "-Astable-features" "--sysroot" "/home/user/.cache/miri/HOST" "-L" "/tmp/compiletestSKklR3/null_pointer_write.stage-id.aux"
    Error {
        line_num: 3,
        kind: Some(
            Error,
---
.......... (60/61)
          (61/61)


/checkout/src/test/rustdoc-gui/search-tab-selection-if-current-is-empty.goml search-tab-selection-if-current-is-empty... FAILED
[ERROR] (line 6) TimeoutError: waiting for selector "#titles" failed: timeout 30000ms exceeded: for command `wait-for: "#titles"`
[ERROR] (line 7) "#titles > button:nth-of-type(1)" not found: for command `assert-attribute: ("#titles > button:nth-of-type(1)", {"class": "selected"})`
Build completed unsuccessfully in 0:00:48

@oli-obk
Copy link
Contributor

oli-obk commented Mar 24, 2022

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

@JakobDegen
Copy link
Contributor Author

Was that two different unrelated failures? The miri failure and the rustdoc timeout? (how did this even cause the miri failure?)

@oli-obk
Copy link
Contributor

oli-obk commented Mar 24, 2022

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

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 24, 2022
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
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 24, 2022
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
@Dylan-DPC
Copy link
Member

@bors r-

(till we solve the miri issue )

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 24, 2022
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
@JakobDegen
Copy link
Contributor Author

Yeah, and the rustdoc timeout seems possibly spurious? Also unsure how I would have caused that

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 25, 2022
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
@bors bors merged commit c66e0c8 into rust-lang:master Mar 25, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 25, 2022
@JakobDegen JakobDegen deleted the mir-phase-docs branch August 10, 2022 00:31
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-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants