Repository navigation
main function missing in coverage report #40
Description
What
The file implementing the main function is not shown in the coverage report, even though it is part of the coverage scope. This makes the coverage report a bit misleading. The file has no existing unit test.
How to reproduce:
- Download latest llvm coverage report from lifecycle https://github.com/eclipse-score/lifecycle/actions/runs/38761636992/job/116514132122
- Search for main.cpp - does not exit
- main.cpp is part of the coverage scope, see launch_manager target. Its alias is part of the coverage scope
Acceptance Criteria (DoD)
bug accepted / rejected
How
No response
Activity
NicolasFussberger commentedon Oct 16, 2026
I learned now this is probably not specific to the
mainfunction, but is the same for any file which is not compiled because it has no test.dcalavrezo-qorix commentedon Oct 16, 2026
Accepted as a bug, and your follow-up is the right generalisation with one precision: the file is not missing because it has no test, it is missing because it is the own source of a
cc_binary.What happens.
main.cppis in the scope: the lifecycle artifact lists it inunmapped_files.txtasno-data, so the aspect did collect it through thelaunch_manageralias. A file appears in the HTML at 0 % only when some baseline object carries coverage mapping for it. The aspect takes those baseline objects from the.aarchives in a target'sCcInfolinking context (coverage_scope.bzl,_coverage_scope_aspect_impl). Acc_binarylinks its own objects straight into the executable;main.ois in no archive and the executable itself is not collected, so there is no object with mapping formain.cpp, llvm-cov cannot list it, and it ends up inunmapped_files.txtinstead of the report. Every untested library source in scope does get its 0 % row because its archive is collected; only the own sources ofcc_binarytargets are affected.Fix. Collect the coverage-built executable of a
cc_binaryas a baseline object, the way the aspect already does forrust_binary(CrateInfo.output). The reporter already passes all baseline objects to onellvm-cov --empty-profilecall, which merges a file seen in both the executable and an archive, so no duplicate rows. Plus an end-to-end case: the consumer workspace has arust_binaryin scope but nocc_binary; adding one with an untestedmain.cpppins the behaviour.I will put up the PR.
dcalavrezo-qorix commentedon Oct 16, 2026
Fix in #44: the aspect now collects the coverage-built executable of a
cc_binaryas baseline object, somain.cppappears at 0 %. The end-to-end workspace pins the case on both backends.scope: a cc_binary executable is the baseline object of its sources
scope: a cc_binary executable is the baseline object of its sources
dcalavrezo-qorix commentedon Oct 16, 2026
@NicolasFussberger could you have a look at the validation on lifecycle, eclipse-score/lifecycle#804 (draft, pinned to the fix by
git_override)? Its Linux coverage artifact now listsscore/launch_manager/src/daemon/src/main.cppat 0 % and the file is gone fromunmapped_files.txt. If that is what you expect, the fix goes out as 0.4.2 and lifecycle takes the version bump instead of the override.dcalavrezo-qorix commentedon Oct 16, 2026
Thanks, and good catch. Confirmed in the artifact: the LCOV says 0 of 3 lines for
main.cpp, the HTML index says 100 % (3/3). The HTML is wrong.Cause: the HTML is produced by one
llvm-cov showover the test binaries plus the baseline objects with the merged test profile. An executable brings a function calledmain, the one unmangled name every test binary also has. With the same structural hash as a test'smain(two short, linear mains), llvm-cov attributes the test's execution counts to it, hence 100 %; with a different hash llvm-cov drops it as mismatched, which is what my end-to-end workspace shows (no row at all). The LCOV is right because baseline-only files are taken from a separate--empty-profilerun. Library archives never containmain, so this did not show before.Fix, going into #44 before it merges: the HTML pages and index rows of baseline-only files come from their own
--empty-profilerun and are spliced into the report, mirroring what the LCOV path already does; the index totals, which the effective-coverage gate reads, are recomputed. The end-to-end test will check the index row ofmain.cppat 0 %, not only the LCOV. I will update lifecycle#804 to the new commit when it is ready.dcalavrezo-qorix commentedon Oct 16, 2026
@NicolasFussberger the HTML is fixed on the PR branch and lifecycle#804 now points at it. Linux coverage run 38912573302 of that draft:
score/launch_manager/src/daemon/src/main.cppHTML index row and LCOV agree now (
LH:0), and the totals include the file. Cause and fix are in coverage_tool#44, second commit: baseline-only files are rendered in their own--empty-profilerun and spliced into the index, so an executable'smaincan no longer pick up a test binary's counts.scope: a cc_binary executable is the baseline object of its sources (e…
dcalavrezo-qorix commentedon Oct 19, 2026
Released in score_coverage 0.4.2 (https://github.com/eclipse-score/coverage_tool/releases/tag/v0.4.2), in the registry since today. lifecycle takes it in eclipse-score/lifecycle#804, which replaces the validation override with the version bump.