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

Make the success arms of if lhs || rhs meet up in a separate block #121784

Merged
merged 1 commit into from
Mar 1, 2024

Conversation

Zalathar
Copy link
Contributor

Extracted from #118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.


In the previous code (#111752), the success block of lhs would jump directly to the success block of rhs. However, rhs_success_block could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.


I think the reason we currently get away with this is that rhs_success_block usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.

In the previous code, the success block of `lhs` would jump directly to the
success block of `rhs`. However, `rhs_success_block` could already contain
statements that are specific to the RHS, and the direct goto causes them to be
executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks
can both jump to.
@rustbot
Copy link
Collaborator

rustbot commented Feb 29, 2024

r? @cjgillot

rustbot has assigned @cjgillot.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added 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. labels Feb 29, 2024
@rustbot
Copy link
Collaborator

rustbot commented Feb 29, 2024

Some changes occurred in match lowering

cc @Nadrieril

@Zalathar
Copy link
Contributor Author

cc @dingxiangfei2009, do you know whether the current behaviour is intentional or not?

@Zalathar
Copy link
Contributor Author

Before and after MIR graphs for test_or in tests/mir-opt/building/logical_or_in_conditional.rs:

BEFORE

_or-pre

AFTER

_or-post

Block 8 gets split into blocks 8 and 9, because the StorageDead statements are no longer on the LHS success path.

@dingxiangfei2009
Copy link
Contributor

dingxiangfei2009 commented Feb 29, 2024

Hey @Zalathar. That is indeed an oversight from my side and it was not intentional. Let's add the success pads as you have set up in this PR.

@Nadrieril
Copy link
Member

LGTM

r? @Nadrieril

@bors r+ rollup=always

@bors
Copy link
Contributor

bors commented Feb 29, 2024

📌 Commit a7832b1 has been approved by Nadrieril

It is now in the queue for this repository.

@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 Feb 29, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Mar 1, 2024
Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
…kingjubilee

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117156 (Convert `Unix{Datagram,Stream}::{set_}passcred()` to per-OS traits)
 - rust-lang#119199 (Add arm64ec-pc-windows-msvc target)
 - rust-lang#120468 (Add a new `wasm32-wasip1` target to rustc)
 - rust-lang#120504 (Vec::try_with_capacity)
 - rust-lang#121416 (Improve error messages for generics with default parameters)
 - rust-lang#121475 (Add tidy check for .stderr/.stdout files for non-existent test revisions)
 - rust-lang#121736 (Remove `Mutex::unlock` Function)
 - rust-lang#121784 (Make the success arms of `if lhs || rhs` meet up in a separate block)
 - rust-lang#121818 (CFI: Remove unused `typeid_for_fnsig`)

r? `@ghost`
`@rustbot` modify labels: rollup
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Mar 1, 2024
Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
…kingjubilee

Rollup of 8 pull requests

Successful merges:

 - rust-lang#117156 (Convert `Unix{Datagram,Stream}::{set_}passcred()` to per-OS traits)
 - rust-lang#119199 (Add arm64ec-pc-windows-msvc target)
 - rust-lang#120468 (Add a new `wasm32-wasip1` target to rustc)
 - rust-lang#121416 (Improve error messages for generics with default parameters)
 - rust-lang#121475 (Add tidy check for .stderr/.stdout files for non-existent test revisions)
 - rust-lang#121736 (Remove `Mutex::unlock` Function)
 - rust-lang#121784 (Make the success arms of `if lhs || rhs` meet up in a separate block)
 - rust-lang#121818 (CFI: Remove unused `typeid_for_fnsig`)

r? `@ghost`
`@rustbot` modify labels: rollup
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2024
Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2024
Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#119199 (Add arm64ec-pc-windows-msvc target)
 - rust-lang#121416 (Improve error messages for generics with default parameters)
 - rust-lang#121475 (Add tidy check for .stderr/.stdout files for non-existent test revisions)
 - rust-lang#121736 (Remove `Mutex::unlock` Function)
 - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrte check)
 - rust-lang#121784 (Make the success arms of `if lhs || rhs` meet up in a separate block)
 - rust-lang#121818 (CFI: Remove unused `typeid_for_fnsig`)
 - rust-lang#121819 (Handle stashing of delayed bugs)
 - rust-lang#121828 (Remove unused fluent messages)
 - rust-lang#121831 (Fix typo in comment)

r? `@ghost`
`@rustbot` modify labels: rollup
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2024
Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#119199 (Add arm64ec-pc-windows-msvc target)
 - rust-lang#121416 (Improve error messages for generics with default parameters)
 - rust-lang#121475 (Add tidy check for .stderr/.stdout files for non-existent test revisions)
 - rust-lang#121736 (Remove `Mutex::unlock` Function)
 - rust-lang#121784 (Make the success arms of `if lhs || rhs` meet up in a separate block)
 - rust-lang#121818 (CFI: Remove unused `typeid_for_fnsig`)
 - rust-lang#121819 (Handle stashing of delayed bugs)
 - rust-lang#121828 (Remove unused fluent messages)
 - rust-lang#121831 (Fix typo in comment)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
…iaskrgr

Rollup of 12 pull requests

Successful merges:

 - rust-lang#120646 (Fix incorrect suggestion for uninitialized binding in pattern)
 - rust-lang#121416 (Improve error messages for generics with default parameters)
 - rust-lang#121475 (Add tidy check for .stderr/.stdout files for non-existent test revisions)
 - rust-lang#121580 (make unused_imports less assertive in test modules)
 - rust-lang#121736 (Remove `Mutex::unlock` Function)
 - rust-lang#121784 (Make the success arms of `if lhs || rhs` meet up in a separate block)
 - rust-lang#121818 (CFI: Remove unused `typeid_for_fnsig`)
 - rust-lang#121819 (Handle stashing of delayed bugs)
 - rust-lang#121828 (Remove unused fluent messages)
 - rust-lang#121831 (Fix typo in comment)
 - rust-lang#121850 (Make `ZeroablePrimitive` trait unsafe.)
 - rust-lang#121853 (normalizes-to: handle negative impls)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1a4c93e into rust-lang:master Mar 1, 2024
11 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Mar 1, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 1, 2024
Rollup merge of rust-lang#121784 - Zalathar:if-or-converge, r=Nadrieril

Make the success arms of `if lhs || rhs` meet up in a separate block

Extracted from rust-lang#118305, where this is necessary to avoid introducing a bug when injecting marker statements into the then/else arms.

---

In the previous code (rust-lang#111752), the success block of `lhs` would jump directly to the success block of `rhs`. However, `rhs_success_block` could already contain statements that are specific to the RHS, and the direct goto causes them to be executed in the LHS success path as well.

This patch therefore creates a fresh block that the LHS and RHS success blocks can both jump to.

---

I think the reason we currently get away with this is that `rhs_success_block` usually doesn't contain anything other than StorageDead statements for locals used by the RHS, and those statements don't seem to cause problems in the LHS success path (which never makes those locals live).

But if we start adding meaningful statements for branch coverage (or MC/DC coverage), it's important to keep the LHS and RHS blocks separate.
@Zalathar Zalathar deleted the if-or-converge branch March 1, 2024 21:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

6 participants