[Zalathar]

This PR adds branch coverage instrumentation for individual arms in match expressions.

It seems to work well in most cases. However, the current implementation cannot handle match expressions containing or-patterns |, and therefore ignores such match expressions entirely.

(More specifically, it ignores a match expression if any of its Candidates has pre_binding_block = None.)

---

Right now I'm not sure whether this should be merged as-is (to provide a useful subset of functionality, and avoid bit-rot), or should be left as a draft until the or-pattern limitation can be lifted (could potentially require major rework).

lgtm, the added tests really speak for themselves 🎉
left a small style nit

Some small style updates (diff).

I noticed that I accidentally included my let-else test as well, but instead of removing it, I decided to just add my if-let test as well. Both of these test show that the respective features don't support branch coverage yet.

(diff)

Discard match expressions early if they have <2 arms (diff).

After investigating some more, I realised that my scheme for making the false-branch expressions isn't accounting for the actual control flow around match guards.

For matches with no guards, the false-count for any arm is just the sum of the execution counts of all subsequent arms.

But for an arm with a guard, we also need to subtract the number of times that the match succeeded but the guard failed. We're currently failing to do that, which is why we get inflated counts, which then mess up all earlier arms too.

For now I've updated the implementation to skip any match expressions that have guards, so that at least we aren't producing wrong branch-coverage numbers for them (diff).

More style updates (diff).

It looks like the point where we know an arm's pre-binding block and its guard-succeeded block is just after the call to bind_pattern in lower_match_arms.

Is there a good way to forward this information to BranchInfoBuilder?

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

Rebasing this on top of #123409 turned out to be very difficult (due to how the branch and MC/DC code have become interdependent), so I've filed #124217 to help relieve that tension, separately from the branch coverage changes that will be built on top of it.

I am wondering why the pattern _ and the guard black_box(false) are in the same code region, while there are 2 branch expressions.

I would have expected the guard to have its own counter displayed underneath

   LL|      1|        _ if black_box(false) => {}
                           ^1                  ^0

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

Brushed some of the cobwebs off this PR.

I still don't want to proceed without a plan for how to handle or-patterns, but at least this implementation is now a more up-to-date reference.

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

#127159 should make your life easier.

I also want to add a link here to https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Details.20of.20match.20guard.20semantics/near/448161106, from which I learned that the interaction between or-patterns and guards is more complex than I had thought, because the guard might need to be evaluated multiple times per match in the general case.

@Zalathar any updates on this? thanks