]> git.lizzy.rs Git - rust.git/commit
Auto merge of #83774 - richkadel:zero-based-counters, r=tmandry
authorbors <bors@rust-lang.org>
Sat, 3 Apr 2021 06:27:03 +0000 (06:27 +0000)
committerbors <bors@rust-lang.org>
Sat, 3 Apr 2021 06:27:03 +0000 (06:27 +0000)
commit836c31742687ba4e2f857b5b698e1e9e6b67619c
tree29f52f27b9fea22a5b870177880d37e76e333e05
parentcb1713640532ca829479554459406e152213e95c
parent7ceff6835abc3ce991e1a8cdcbe2be2730335a65
Auto merge of #83774 - richkadel:zero-based-counters, r=tmandry

Translate counters from Rust 1-based to LLVM 0-based counter ids

A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.

See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170

Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.

It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!

r? `@tmandry`
FYI: `@wesleywiser`