Known limitations of branch coverage instrumentation

Branch coverage is known to support these branching language constructs:

• if and while
  • Includes if let and let-chains
  • Treats nested || and && as separate branches
  • while desugars to if before MIR building, so we support it as a consequence of supporting if
• Standalone || and && expressions
  • Nested || and && are treated as separate branches
  • The final operand is not a branch, but can be optionally treated as one via #125756
• let-else statements
• Match arm guards
  • These also desugar to if expressions before MIR building
    • This also means that we naturally support if let guards
  • But their presence makes it more complicated to instrument match arms, as described below

Branch coverage is known to not yet support these branching language constructs:

• Individual arms and or-patterns in match expressions
  • We need to be sure to support (or gracefully not support) all four combinations of:
    • Arms with/without guards
      • The guards themselves are already supported (as indicated above), but their presence also complicates how we instrument the enclosing match arm, and other match arms in the same match
      • Note that the combination of guards and or-patterns results in particularly complex control-flow, because if a guard fails then we keep searching for other or-pattern matches in the same arm
    • Arms with/without or-patterns, including arbitrary nesting
  • #124154
    • This draft does not support or-patterns, and might not be able to support them without substantial changes (requiring a different approach)
    • This draft uses complex counter expressions to work around not being able to instrument all the appropriate points in the control-flow graph directly; this ties back into concerns about or-patterns
• The try ? operator (which conditionally returns)
  • This is desugared to a match expression, so once we support those, supporting ? should mostly be a matter of expansion-span bookkeeping
• .await expressions (which implicitly “return” when the enclosing future is dropped)
  • This can probably be excluded from any MVP of branch coverage, unless it turns out to be unexpectedly easy after supporting ?
  • But some users will presumably want this in the long run
• Any of the above branching constructs that are introduced by macro expansion
  • The current implementation discards any branch span that isn't “directly visible” in the function body

Relevant PR links:

• #122322
• #124223
• #124154

(Rewritten on 2024-07-11; see edit history for the old text.)

Start by reading the relevant PRs #122322, #124223, and #124154, then compare their approaches with the unsupported constructs listed here. The issue names no files or tests, and completion would require deciding which limitations to address and defining support for them.