Support mcdc analysis for pattern matching #124278

ZhuUx · 2024-04-23T05:38:05Z

To finish the second task at #124144.

Changes

Implement branch coverage for pattern matching specific to mcdc. As suggested at #124217, mcdc would better implement its own branch coverage methods for pattern match.
That means, coverage-options=mcdc may give different branch coverage results of pattern matching with coverage-options=branch temporarily.
Generate decision mappings for all refutable patterns in match.

Note. The results might be a bit counter intuitive due to reorder as this comment introduces.

rustbot · 2024-04-23T05:38:12Z

rustbot has assigned @wesleywiser.
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

ZhuUx · 2024-04-23T05:42:47Z

For now there are still some work need to do and some code is not well optimized to reduce work in merging #124255 .
r? @ghost
@rustbot label +A-code-coverage
@rustbot author

rustbot · 2024-04-23T05:42:50Z

Failed to set assignee to ghost: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

Lambdaris · 2024-04-24T09:45:02Z

Determining decision of pattern matching is more tricky than expected. I should write it down here in case someone feels confused about it.
I'm not sure if rustc promises anything about the order of checked pattern (probably not), so the description here should be only taken as a specific way determined by the implementation of compiler when this pr is drafting.

The first rule is that candidate is constructed where all match pairs representing | pattern (directly) are moved to last
This is done at simplify_match_pairs.
For the example compiler checks C first because A | B is or pattern while C is not directly (though it has an or sub pattern).

The second rule is the first pair will be removed and compiler will insert its sub pairs into the candidate's match pairs if it is "full matched"
This is done at sort_candidate.
So when compiler checks C first, it removes it and takes match pair representing X | Y as the candidate's last match pair. If the sub pattern in C were not |, it would be inserted at front of all or patterns as the code suggests.

Thus in all, the evaluate order of if let ( A | B, C (X | Y) ) = val is:

Check whether val.1 is C,
Check whether val.0 is A | B,
Check whether val.1.0 is X | Y.

While the order of if let (A | B, C(X)) = val is:

Check whether val.1 is C,
Check whether val.1.0 is X,
Check whether val.0 is A | B.

And the order of if let (A(Z), C) = val is:

Check whether val.0 is A,
Check whether val.0.0 is Z,
Check whether val.1 is C.

A more mischievous example is if let (A | B, C (X | Y, Z), D) = val, its control flow would be like:

Check whether val.1 is C,
Check whether val.2 is D,
Check whether val.1.1 is Z,
Check whether val.0 is A | B,
Check whether val.1.0 is X | Y.

Hopefully the decision structure were not taken as mischief by users.

ZhuUx · 2024-04-28T03:00:45Z

I have pushed an impractical commit to show design for constructing decisions and mcdc branches of pattern matching.
Mostly is in MCDCDecisionBuilder. I'd like to finish it after merging #124255 and #124399 because the way to inject block marker should be changed.
But still any comments about it are welcomed.

bors · 2024-04-29T14:53:42Z

☔ The latest upstream changes (presumably #124255) made this pull request unmergeable. Please resolve the merge conflicts.

Split mcdc code to a sub module of coverageinfo A further work from rust-lang#124217 . I have made relatively large changes when working on rust-lang#124278 so that it would better split them from `coverageinfo.rs` to avoid potential troubling merge work with improved branch coverage by `@Zalathar` . Besides `BlockMarkerGenerator` is added to avoid ownership problems (mostly needed for following change of rust-lang#124278 ) All code changes are done in [a37d737a](rust-lang@a3d737a) while the second commit just renames the file. cc `@RenjiSann` `@Zalathar` This will impact your current work.

ZhuUx · 2024-05-10T03:09:01Z

Implementation for if-let has been drafted. Due to llvm does not support nested decisions yet tests for let-chains are not added. I should try to reduce coverage expressions and investigate if it works for matching guards later.

bors · 2024-05-10T18:57:20Z

☔ The latest upstream changes (presumably #124972) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2024-07-12T06:19:39Z

☔ The latest upstream changes (presumably #127635) made this pull request unmergeable. Please resolve the merge conflicts.

coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 `@rustbot` label +A-code-coverage

coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ``@rustbot`` label +A-code-coverage

coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ```@rustbot``` label +A-code-coverage

Rollup merge of rust-lang#127758 - Zalathar:expression-used, r=oli-obk coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ```@rustbot``` label +A-code-coverage

bors · 2024-07-16T11:12:17Z

☔ The latest upstream changes (presumably #127796) made this pull request unmergeable. Please resolve the merge conflicts.

JohnCSimon · 2024-09-03T22:49:29Z

@ZhuUx
ping from triage - can you post your status on this PR? This PR has not received an update in a few months and you have merge conflicts

ZhuUx · 2024-09-04T01:40:45Z

@ZhuUx ping from triage - can you post your status on this PR? This PR has not received an update in a few months and you have merge conflicts

Updated to non-conflicted version. Sorry I am trying to fix a bug that with certain -C metadata rustc would panic on some async functions after resolving conflicts. Also this pr is blocked by #126733 . So there is still some work to do.

bors · 2024-09-10T23:09:58Z

☔ The latest upstream changes (presumably #130200) made this pull request unmergeable. Please resolve the merge conflicts.

ZhuUx · 2024-10-09T07:35:39Z

Rebased to the latest since #126733 has been merged.

r? @Zalathar

Nevertheless I would suggest delaying this pr if we are going to refactor lower_match_arms further.
~~And two known issues worth noting as follows.~~ LLVM-20 will fix the two issues.

tests/coverage/mcdc/match_misc.rs

bors · 2024-10-25T11:13:05Z

☔ The latest upstream changes (presumably #132128) made this pull request unmergeable. Please resolve the merge conflicts.

…n and change the way to calculate decision depth

…thout updating global bitmap

rustbot assigned wesleywiser Apr 23, 2024

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 Apr 23, 2024