Update dependency score_coverage to v0.2.0 - autoclosed - #590
Closed
eclipse-score-bot wants to merge 1 commit into
Closed
eclipse-score-bot wants to merge 1 commit into
eclipse-score-bot wants to merge 1 commit into
Conversation
eclipse-score-bot
requested review from
arkjedrz,
fbaeuerle and
pawelrutkaq
as code owners
September 16, 2026 13:06
Contributor
|
Documentation preview for this pull request is available at: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.1.0→0.2.0Release Notes
eclipse-score/coverage_tool (score_coverage)
v0.2.0In 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
.cppof 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.txtEvery 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.no-datadeclaration-onlytimerfd.hnext totimerfd.cpp), and that file is measured.compiled-without-code#includelines. Header-only libraries carry such a placeholder so that Bazel produces a library archive.Two things this list is not: it is not part of the coverage percentage, and it does not say why a
no-datafile was never compiled. That needs a look at the file.For integrators
score_coverage_scopegained thepath_mapandsource_filesoutput groups,score_coverage_reporterpasses them on.strip_include_prefix/include_prefixare 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.foo/bar.hno longer suppresses an in-scopesrc/foo/bar.h.includes = [...]are system headers for clang and produce no coverage in the consuming translation units. Follow-up planned.This PR was generated by #infrastructure automation. Contact us if you have any questions or feedback.