Known limitations of branch coverage instrumentation

[Zalathar]

Initial branch coverage support was added in #122322.

That implementation instruments ordinary if expressions, along with some other constructs that desugar into them, such as while expressions, the lazy boolean operators &&/||, and if guards in match expressions.

However, there are some other branching constructs in Rust that are currently not instrumented for branch coverage:

• if let and while let expressions (including let-chains and let-guards)
  • coverage: Branch coverage support for let-else and if-let #124223
• let-else statements
  • coverage: Branch coverage support for let-else and if-let #124223
• Individual arms of match expressions
  • coverage: Treat each match arm as a "branch" for branch coverage #124154
• The try ? operator (which conditionally returns)
• .await expressions (which implicitly “return” when the enclosing future is dropped)

It would be nice to support some or all of these in the future.

---

Currently we also discard any branch coverage spans that were produced by expansion (e.g. desugaring or macros). As mentioned below, this will be an obstacle to supporting the try ? operator, and it would also be nice to support branch coverage for macro-expanded code if possible.

[Zalathar]

Based on my investigations so far:

• If-let (and friends) and let-else are relatively easy to support. I have implementations of them, though I haven't filed PRs yet because I'm wary of making any changes that will accidentally make the other branching constructs harder to support.
• Match arms are tricky to support at the moment. Conceptually, it makes sense to treat each arm (except the last) as a branch, with the true arm leading to the guard check (if any) followed by the corresponding body, and the false arm leading to the test for the next arm. However, that control-flow structure doesn't necessarily exist in the lowering from THIR to MIR, so we don't always have a suitable place to insert block markers.
  • I have a sketch of a plan for how to deal with this, by inserting block markers in all the true arms, and then using coverage expressions to create synthetic counts for the false arms. However, this will require some non-trivial reshuffling of how the InstrumentCoverage MIR pass currently deals with branch coverage information.
• The try operator desugars to a match expression, so if we support those, then we should be close to supporting try as well.
  • The caveat here is that we currently ignore all branches that come from expansion of any kind, so once we support match arms, we'll need to deal with that limitation as well.
• Await seems complicated enough that I'm inclined to put it in the too-hard basket for now.

[Zalathar]

There's also some discussion at #79649 (comment) about whether the right-hand-side of a lazy boolean expression (&&/||) should be treated as a “branch” condition, even when it's not part of an if condition.

My view is that “branch coverage” should not be in the business of instrumenting things that clearly aren't branches at the language level, at least not by default. There are valid use-cases for that behaviour, but if it exists then it should require some additional level of opt-in beyond just enabling branch coverage.

(If people want to discuss this point further, I would suggest creating a separate issue for that discussion.)

[Lambdaris]

Is there a draft folk for if-let pattern?

I have tried a bit and found a possibly feasible way to insert block markers, see a naive draft.

Because if let would be taken as match guard this method may solve them together (not sure, I just check it could find the true/false blocks for code like if let (En::A(Some(a)) | En::B(a), En::C(b)) = _.

By this then BranchSpan might need to change its true_marker and false_marker to Vec<BlockMarkerId>.

[Zalathar]

I managed to get my match-arm idea working, so I'll try to tie up the loose ends and post it as a PR.

[Zalathar]

#124154 shows my current approach to instrumenting match arms for branch coverage.

[Zalathar]

I now have draft PRs for if-let, let-else, and match arms (without or-patterns).

[ZhuUx]

Noticed the match arms pay attention to occasion like comment at first line of make_expression in counters.rs, I think it may be better put a note here rather reviews of the current two prs.

Many redundant expressions like this may be introduced by match arms.
The root cause is rustc may generate several test blocks for certain pattern. For example, code (A | B, C | D) will generate CFG like code

if match A {
    if match C {
        // Assume here is BcbCounter 1
    }  else if match D {
        // ...
    }
} else if match B {
    if match C {
        // Assume here is BcbCounter 2
    }  else if match D {
        // ...
    }
}

The true_term of C apparently should be BcbCounter 1 + BcbCounter 2. Pattern (A | B, C | D, E | F) even make terms of E more sophisticated. Actually they are just composition of several BcbCounter::Counter thus there probably many of intermediate expressions can be optimized out.

However, given that Expressions does not have runtime overhead the main side effect of these redundant expressions might only make people who read mir directly distressed. Further if we wanted to minimize the number of expressions, probably do it in llvm is better.

[ZhuUx]

The true_term of C apparently should be BcbCounter 1 + BcbCounter 2. Pattern (A | B, C | D, E | F) even make terms of E more sophisticated. Actually they are just composition of several BcbCounter::Counter thus there probably many of intermediate expressions can be optimized out.

This might not be "apparent". We also can view C as several branches sharing one span. By this view most work could be simplified but users would be confused with many branches in llvm-cov reports.