Uh oh!
There was an error while loading. Please reload this page.
Coverage: Add condition coverage - #124402
Conversation
rustbot
commented
Apr 26, 2024
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jieyouxu (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
This comment has been minimized.
This comment has been minimized.
rustbot
commented
Apr 26, 2024
Some changes occurred in coverage tests. cc @Zalathar |
7a80098 to
290a532Comparejieyouxu
commented
Apr 26, 2024
The changes look reasonable to me. However, I'm not very familiar with MIR building and if the change to conditional lowering is desirable, so I would like another compiler reviewer to also take a look at this PR. r? compiler |
Zalathar
commented
Apr 28, 2024
I plan to take a look at this sometime this week. |
Zalathar
commented
Apr 28, 2024
@rustbot label +A-code-coverage |
Zalathar
commented
Apr 29, 2024
The main thing that worries me about this change that it adds a big chunk of coverage-specific complexity right in the middle of MIR building, which is something I've generally been trying very hard to avoid. I suspect there is probably a less-disruptive way to get the desired behaviour here, perhaps via one of:
|
Zalathar
commented
Apr 29, 2024
Also see #124507 for my proposed handling of the coverage level in |
RenjiSann
commented
Apr 29, 2024
I was concerned by the same thing, that's why I added a big comment to document what is happening. I take your point and share your concern, but I probably lack experience with the compiler codebase to see a better alternative. |
michaelwoerister
commented
Apr 29, 2024
r? mir |
290a532 to
c138d40CompareRenjiSann
commented
Apr 29, 2024
Rebase on master + splitting tests commits to get before/after diff (diff) |
bors
commented
Apr 30, 2024
☔ The latest upstream changes (presumably #124507) made this pull request unmergeable. Please resolve the merge conflicts. |
c138d40 to
c06499aCompare
This comment has been minimized.
This comment has been minimized.
c06499a to
b95334eCompareb95334e to
bf51676CompareRenjiSann
commented
Apr 30, 2024
Rebase on #124399 |
Zalathar
commented
May 3, 2024
I spent some time trying to find an alternative, and #124644 shows what I was able to come up with. (You were right that it's not easy! I went down several dead-ends before finally arriving at this approach.) |
superseded by #124644, which implement the same logic while being less intrusive in the main MIR building code. |
coverage: Optionally instrument the RHS of lazy logical operators (This is an updated version of rust-lang#124644 and rust-lang#124402. Fixesrust-lang#124120.) When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch. That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at rust-lang#124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators. --- As discussed at rust-lang#124120 (comment), this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work. `@rustbot` label +A-code-coverage
coverage: Optionally instrument the RHS of lazy logical operators (This is an updated version of rust-lang#124644 and rust-lang#124402. Fixesrust-lang#124120.) When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch. That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at rust-lang#124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators. --- As discussed at rust-lang#124120 (comment), this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work. ``@rustbot`` label +A-code-coverage
coverage: Optionally instrument the RHS of lazy logical operators (This is an updated version of rust-lang#124644 and rust-lang#124402. Fixesrust-lang#124120.) When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch. That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at rust-lang#124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators. --- As discussed at rust-lang#124120 (comment), this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work. ```@rustbot``` label +A-code-coverage
coverage: Optionally instrument the RHS of lazy logical operators (This is an updated version of rust-lang#124644 and rust-lang#124402. Fixesrust-lang#124120.) When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch. That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at rust-lang#124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators. --- As discussed at rust-lang#124120 (comment), this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work. ````@rustbot```` label +A-code-coverage
Rollup merge of rust-lang#125756 - Zalathar:branch-on-bool, r=oli-obk coverage: Optionally instrument the RHS of lazy logical operators (This is an updated version of rust-lang#124644 and rust-lang#124402. Fixesrust-lang#124120.) When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch. That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at rust-lang#124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators. --- As discussed at rust-lang#124120 (comment), this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work. ````@rustbot```` label +A-code-coverage
This MR adds
condition-coverageas defined in #124120 .This is done by removing the "optimization" that prevents the compiler to create a branch for the last operand of a boolean expression that is not an
if-elseblock decision.@Lambdaris
@Zalathar
@ZhuUx