Support mcdc analysis for pattern matching

[ZhuUx]

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]

r? @wesleywiser

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]

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]

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]

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.

We call patterns like ( A | B, C (X | Y) ) as candidates, each candidate has match pairs which indicates sub patterns and also has their "sub pairs". For example, candidate for ( A | B, C (X | Y) ) has match pairs for A | B (let's call it M1) and C (X | Y) (M2) separately. Also M1 has sub pairs for A and B and M2 has sub pair X | Y.

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:

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

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

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

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

1. Check whether val.0 is A,
2. Check whether val.0.0 is Z,
3. 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:

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

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

[ZhuUx]

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]

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

[ZhuUx]

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]

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

[bors]

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

[ZhuUx]

Thanks to @Nadrieril now I could find a way to treat each arm in match statements as a decision.

The basic idea is to update test vectors of every decision in every arms. For instance,

match val {
    Pat::A | Pat::B => { /* update test vectors of `Pat::A | Pat::B` and `Pat::C | Pat::D` here */}
    Pat::C | Pat::D=> { /* update test vectors of `Pat::A | Pat::B`  and `Pat::C | Pat::D` here */}
    _ => { /* update test vectors of `Pat::A | Pat::B`  and `Pat::C | Pat::D` here */}
}

By updating test vectors of all decisions simultaneously we can deal with tests affecting different decisions. Fortunately we have implemented decision depth to such cases.

[ZhuUx]

decision_ends is introduced because:

1. Candidates with | may not have pre_binding_block when matching finishes.
2. For every arm in match statements, arm_block is generated in lower_match_arms and immediately compiler digs into code in the arm, which might contain many other decisions.

Hence when a PatternDecisionCtx is finished, we do not know all blocks which are "ends" of these decisions. Instead we fulfill them in add_ends_to_decision later. Because decisions produced by same ctx share same ends, Rc<RefCell<_>> is used here.

[ZhuUx]

Changed a bit to fit with constant folding. The main goal is to find all false blocks of branches and let the false term be sum of all counters in false blocks.
Now it uses two variants of MCDCBranchMarker to represent markers for boolean expressions and pattern matching respectively. The difference on false blocks between boolean expressions and pattern matching is the true blocks and false blocks of boolean expressions possibly does not share same predecessor in nested decisions. While for pattern matching, false block might not exist when building mir (such false blocks are inserted when instrumenting coverage statements for bcb edges). Hence it's hard to find a unified way to get false blocks for boolean expressions and patterns.
See comparison for details.

[ZhuUx]

Upon compiling my projects with "--coverage-options=mcdc", I have found there are still some work to do with pattern matching expanded by macros. I would like to investigate whether we should refactor this implementation for macros.
@rustbot author