Skip to content

Collect C++ lcov coverage if runtime object not in runfiles#15118

Closed
fmeum wants to merge 1 commit intobazelbuild:masterfrom
fmeum:cc-coverage-shared-library-not-in-runfiles
Closed

Collect C++ lcov coverage if runtime object not in runfiles#15118
fmeum wants to merge 1 commit intobazelbuild:masterfrom
fmeum:cc-coverage-shared-library-not-in-runfiles

Conversation

@fmeum
Copy link
Copy Markdown
Collaborator

@fmeum fmeum commented Mar 24, 2022

Before this commit, collecting C++ coverage in lcov format would fail
at the llvm-cov export step if a shared library listed in the
runtime_objects_list.txt was not contained in the runfiles of the top-
level target. This can happen e.g. if a cc_library depends on a
java_binary that has a cc_binary shared library in its resources.

This is fixed by not including objects that don't exist at runtime
in the llvm-cov invocation.

Fixes #15121.

Before this commit, collecting C++ coverage in lcov format would fail
at the llvm-cov export step if a shared library listed in the
runtime_objects_list.txt was not contained in the runfiles of the top-
level target. This can happen e.g. if a cc_library depends on a
java_binary that has a cc_binary shared library in its resources.

This is fixed by not including objects that don't exist at runtime
in the llvm-cov invocation.
@fmeum fmeum changed the title Collect C++ lcov coverage if runtime object not in runfiles Draft: Collect C++ lcov coverage if runtime object not in runfiles Mar 24, 2022
@fmeum fmeum marked this pull request as ready for review March 25, 2022 09:02
@fmeum fmeum requested a review from lberki as a code owner March 25, 2022 09:02
@fmeum fmeum changed the title Draft: Collect C++ lcov coverage if runtime object not in runfiles Collect C++ lcov coverage if runtime object not in runfiles Mar 25, 2022
@fmeum
Copy link
Copy Markdown
Collaborator Author

fmeum commented Mar 25, 2022

@c-mita I suspect this is also something for you to take a look at. The fix is the most direct one I could think of, but I am completely open to other suggestions (e.g. filtering the runtime objects list in the first place).

@ckolli5 ckolli5 added the team-Rules-CPP Issues for C++ rules label Mar 28, 2022
@ckolli5 ckolli5 requested a review from oquenchil March 28, 2022 22:04
@c-mita c-mita self-assigned this Mar 31, 2022
@oquenchil oquenchil requested review from c-mita and removed request for lberki and oquenchil April 5, 2022 09:56
@fmeum
Copy link
Copy Markdown
Collaborator Author

fmeum commented Apr 13, 2022

@c-mita Do you think that it will be possible to get this PR reviewed in time for the 5.2.0 release? It's the final full blocker for cross-language coverage reports for us and now that java_test has the $collect_cc_coverage attribute, our current workaround of manually setting CC_CODE_COVERAGE_SCRIPT to point to a patched version of this script doesn't work anymore.

Copy link
Copy Markdown
Member

@c-mita c-mita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Sorry for the delay.

@fmeum
Copy link
Copy Markdown
Collaborator Author

fmeum commented Apr 19, 2022

@bazel-io flag

@bazel-io bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Apr 19, 2022
@bazel-io bazel-io closed this in bb6f1a7 Apr 19, 2022
@ckolli5
Copy link
Copy Markdown

ckolli5 commented Apr 19, 2022

@bazel-io fork 5.2.0

@bazel-io bazel-io removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Apr 19, 2022
@fmeum fmeum deleted the cc-coverage-shared-library-not-in-runfiles branch April 20, 2022 09:12
fmeum added a commit to fmeum/bazel that referenced this pull request Apr 20, 2022
Before this commit, collecting C++ coverage in lcov format would fail
at the llvm-cov export step if a shared library listed in the
runtime_objects_list.txt was not contained in the runfiles of the top-
level target. This can happen e.g. if a cc_library depends on a
java_binary that has a cc_binary shared library in its resources.

This is fixed by not including objects that don't exist at runtime
in the llvm-cov invocation.

Fixes bazelbuild#15121.

Closes bazelbuild#15118.

PiperOrigin-RevId: 442799461
ckolli5 pushed a commit that referenced this pull request May 9, 2022
Before this commit, collecting C++ coverage in lcov format would fail
at the llvm-cov export step if a shared library listed in the
runtime_objects_list.txt was not contained in the runfiles of the top-
level target. This can happen e.g. if a cc_library depends on a
java_binary that has a cc_binary shared library in its resources.

This is fixed by not including objects that don't exist at runtime
in the llvm-cov invocation.

Fixes #15121.

Closes #15118.

PiperOrigin-RevId: 442799461
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-Rules-CPP Issues for C++ rules

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No C++ coverage collected when a runtime object is not in runfiles

4 participants