Skip to content

Update dependency score_coverage to v0.2.0 - autoclosed - #590

Closed
eclipse-score-bot wants to merge 1 commit into
mainfrom
renovate/score_coverage-0.x
Closed

eclipse-score-bot wants to merge 1 commit into
mainfrom
renovate/score_coverage-0.x

Conversation

@eclipse-score-bot

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
score_coverage bazel_dep minor 0.1.00.2.0

Release Notes

eclipse-score/coverage_tool (score_coverage)

v0.2.0

In plain words

This release fixes what the first baselibs reports showed and adds one new piece of information to every report.

Third-party code no longer leaks into a module's report. A module that wraps a third-party library (baselibs wraps OpenSSL this way) got that library's 72 header files counted as its own code, at 0 %. They are gone. Only files a module lists itself in its build targets are part of its report.

Every link in the HTML report opens. Some rows pointed at pages that had never been generated, because generated files and files from other repositories were not readable when the report was produced. The report now brings every source file along. File names are the source paths, no longer build-internal paths such as bazel-out/.../_virtual_includes/.... A justification written against such a path needs the source path now.

Headers tested through a test-only twin target are measured. A common pattern declares a library's headers a second time in a test-only target with test flags (baselibs' futurecpp_internal). Tests compile the headers through that second target, and the report did not recognise the result as belonging to the library: 109 futurecpp headers appeared untested. They are now attributed to the library's declared header files.

More untested files show their 0 %. A library archive with one object that contains no code (the placeholder .cpp of a header-only library) was rejected by llvm-cov as a whole, so the other files of that library lost their 0 % entries. Fixed; in baselibs 15 files reappeared.

Untested files the old report could not show are listed. A coverage tool can only measure files that were compiled into a test or a library. A file that nothing compiles has no lines to count, so llvm-cov cannot show it, not even at 0 %. Until now such files were simply absent. The report now lists them, see below.

The file unmapped_files.txt

Every coverage archive now contains unmapped_files.txt, and the job summary shows the same information as a table row and three collapsible sections. It lists every file that belongs to the module's coverage scope but for which no coverage data exists anywhere: no test and no library contains compiled code from it. Such a file counts in no percentage. Each line is a category, a tab and a file name.

Category What it means What to do
no-data The findings. Nothing in the module compiles this file: no source includes the header, or it holds only templates that no test ever uses with a concrete type. For a public API this means no test exercises it. It also catches headers that contain nothing executable (forward declarations, type traits, test mocks); the tool cannot tell those apart from unused API. Look at each file: write a test that uses it, remove it if nobody needs it, or note that it holds nothing testable.
declaration-only A header that only announces functions. The code lives in a source file with the same name (timerfd.h next to timerfd.cpp), and that file is measured. Nothing. Listed for completeness.
compiled-without-code A source file that Bazel compiled but that contains no code of its own, only #include lines. Header-only libraries carry such a placeholder so that Bazel produces a library archive. Nothing. Listed for completeness.

Two things this list is not: it is not part of the coverage percentage, and it does not say why a no-data file was never compiled. That needs a look at the file.

For integrators
  • Consumers instantiate the same two macros as before; only the module version changes. score_coverage_scope gained the path_map and source_files output groups, score_coverage_reporter passes them on.
  • Headers behind strip_include_prefix / include_prefix are reported under their declared path. _virtual_includes/ paths of targets outside the scope are resolved to the declared header by their path tail; ambiguous tails are warned about.
  • The exclusion filter matches each out-of-scope compiled file exactly; an excluded foo/bar.h no longer suppresses an in-scope src/foo/bar.h.
  • Archive members are probed for a coverage mapping and only usable members are passed to llvm-cov (generalises the rlib expansion).
  • Known limit: headers consumed through includes = [...] are system headers for clang and produce no coverage in the consuming translation units. Follow-up planned.
  • Fixes #​5, eclipse-score/baselibs#558.

  • If you want to rebase/retry this PR, check this box

This PR was generated by #infrastructure automation. Contact us if you have any questions or feedback.

@github-actions

Copy link
Copy Markdown
Contributor

Documentation preview for this pull request is available at:
pr-590: https://eclipse-score.github.io/baselibs/pr-590/

@eclipse-score-bot eclipse-score-bot changed the title Update dependency score_coverage to v0.2.0 Update dependency score_coverage to v0.2.0 - autoclosed Sep 16, 2026
@github-project-automation github-project-automation Bot moved this from In Progress to Done in BAS - Baselibs FT Sep 16, 2026
@eclipse-score-bot
eclipse-score-bot deleted the renovate/score_coverage-0.x branch September 16, 2026 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automation bazel Bazel and Starlark build files renovate Renovate Bot

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant