about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/Linker.cpp
diff options
context:
space:
mode:
authorRich Kadel <richkadel@google.com>2021-04-02 00:08:48 -0700
committerRich Kadel <richkadel@google.com>2021-04-02 17:16:36 -0700
commit7ceff6835abc3ce991e1a8cdcbe2be2730335a65 (patch)
tree30405b09690336982eb681147e486ea3f95c3b98 /compiler/rustc_llvm/llvm-wrapper/Linker.cpp
parent138fd56cf9598b4bf016634c768dca128a83a5d7 (diff)
downloadrust-7ceff6835abc3ce991e1a8cdcbe2be2730335a65.tar.gz
rust-7ceff6835abc3ce991e1a8cdcbe2be2730335a65.zip
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!
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/Linker.cpp')
0 files changed, 0 insertions, 0 deletions