coverage: Support match statements in branch coverage

[ranger-ross]

This PR builds on the work original done in #124154. (Also see #124118)

In addition, to supporting match arms this PR also attempts to support or-patterns in match patterns by tracking subbranches.
The current implementation handles the basics but nested or-patterns+match guards still have some issues. I figured I would open a PR with what I have so far to get feedback and to see if I am even headed in the right direction.

r? Zalathar

---

This is my first non-trivial PR for the compiler so apologies if I am doing something wildly incorrect.

[ranger-ross]

@rustbot label +A-code-coverage

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage tests.

cc @Zalathar

[ranger-ross]

Note: There is still a bug with nested or-patterns + match guards being used together.

ie. Branch coverage does not appear to work correctly on this code:

let a = 1;
let b = 2;
match black_box((a, b)) {
    (1, 2 | 3) | (2, 4) if b > 1 => {}
    _ => {}
}

tbh, I am not super sure what the correct behavior for coverage for nested or-patterns.

[Nadrieril]

This means that turning on branch coverage can cause exponential blowups in MIR size, this is unfortunate. Are you sure tracking or-patterns is worth it? (I'm not expert here, just curious)

[Zalathar]

Fair warning that it may take me a while to get around to properly looking at this.

(I also have some general concerns about expanding branch coverage with the rest of the coverage code in its present state, though I haven't looked at this PR closely enough to know whether those concerns apply here.)

[ranger-ross]

No worries, and yeah I was also not in love with the implementation 😅

After opening this PR, I am starting question what the correct behavior is.

I think an argument can be made that a pattern should be considered a single branch. (Either it matches or it doesn't)

But on the other hand I can see value in knowing if the rhs of an or-pattern was never matched.

[Nadrieril]

I'd say if you want to be sure all the parts of your pattern are useful, you can use MC/DC (when we manage to implement it)

[ranger-ross]

I'd say if you want to be sure all the parts of your pattern are useful, you can use MC/DC (when we manage to implement it)

Thats true, I am starting to lean towards patterns being considered a single branch in branch coverage.
Like you mentioned, if someone really needs in depth pattern coverage they can just use MC/DC.

[bors]

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

[sassman]

Is there actually a (Pre-) RFC for the whole branch coverage feature, just to understand the expected and defined behavior better?

I'm asking because I found this issue taiki-e/cargo-llvm-cov#394 that indeed shows an interesting corner case for branch coverage and generics where it's a bit unintuitive what is the right thing to expect to see.

[ranger-ross]

Is there actually a (Pre-) RFC for the whole branch coverage feature, just to understand the expected and defined behavior better?

I did a search for "coverage" in the rust-lang/rfcs repo and found very little about coverage. (and nothing about branch coverage)

After a bit of searching, the origin of the branch coverage feature was merged in #122322 .
We probably need to more formally define the expected behavior. As you mentioned, the correct behavior is sometimes not obvious.

[wesleywiser]

Hi @Zalathar, just a friendly ping from the compiler team triage meeting in case this fell off your todo list 🙂

[Zalathar]

Hi, so the reason I've put my own branch coverage efforts on hold is that I'm pursuing deeper changes to the architecture of coverage instrumentation, to undo some old design decisions that are now causing difficulties.

For that reason, I want to avoid new/expanded features that would make those deep changes harder, since they're hard enough already. And adding branch coverage support for match expressions now would indeed introduce significant obstacles.

(I also have similar concerns about the necessary changes to MIR building, since that code is also quite tricky already, and could use some delicate improvements that would be made harder by adding more coverage-related code.)