Skip to content

coverage: Migrate branch coverage to use CoveragePoint and HIR analysis - #162425

Open
Zalathar wants to merge 1 commit into
rust-lang:mainfrom
Zalathar:branch
Open

coverage: Migrate branch coverage to use CoveragePoint and HIR analysis#162425
Zalathar wants to merge 1 commit into
rust-lang:mainfrom
Zalathar:branch

Conversation

@Zalathar

@Zalathar Zalathar commented Sep 7, 2026

Copy link
Copy Markdown
Member

Historically, the implementation of branch coverage instrumentation (#122322) required keeping a side-table of branch spans associated with opaque marker-statement IDs, which corresponded to injected marker statements. Using similar techniques to #161517, this PR instead injects marker statements that associate the true/false destination blocks with the HirId of the expression being inspected.

While we still rely on injecting markers into the true and false blocks of a condition during MIR building, this approach avoids the need for a separate side-table, as the association between true/false markers can be recovered by matching their HirId.

There is no longer any need to keep track of enclosing ! expressions, because with HirId we can instead walk up the HIR parent chain to find the original condition.

CoverageEarlyInfo and CoverageKind::BlockMarker have been removed, as they
are no longer needed.

@Zalathar Zalathar added the A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) label Sep 7, 2026
@rustbot

rustbot commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 7, 2026
@rustbot

rustbot commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

r? @fee1-dead

rustbot has assigned @fee1-dead.
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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler, mir
  • compiler, mir expanded to 75 candidates
  • Random selection from 20 candidates

@Zalathar

Zalathar commented Sep 7, 2026

Copy link
Copy Markdown
Member Author

CoverageEarlyInfo and BlockMarker could potentially be re-added if needed by some future feature. However, my hope is that HirId and HIR-based analysis should make that unnecessary.

@rust-bors

This comment has been minimized.

While we still rely on injecting markers into the true and false blocks of a
condition during MIR building, this approach avoids the need for a separate
side-table, as the association between true/false markers can be recovered by
matching their HirId.

There is no longer any need to keep track of enclosing `!` expressions, because
with HirId we can instead walk up the HIR parent chain to find the original
condition.

`CoverageEarlyInfo` and `CoverageKind::BlockMarker` have been removed, as they
are no longer needed.
@rustbot

rustbot commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@Zalathar

Zalathar commented Sep 8, 2026

Copy link
Copy Markdown
Member Author

Proactively rerolling as @fee1-dead has usually declined to do reviews of coverage in the past. 👍

If someone wants to take this on, please feel free to ask for context, as there aren't many people with deep knowledge of coverage instrumentation.

r? compiler

@rustbot rustbot assigned dingxiangfei2009 and unassigned fee1-dead Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants