Collect C++ lcov coverage if runtime object not in runfiles #15118
Conversation
This file contains 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
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
changed the title
fmeum
changed the title
|
@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). |
oquenchil
requested review from
c-mita
and removed request for
lberki and
oquenchil
|
@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 |
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
@bazel-io fork 5.2.0 |
bazel-io
removed
the
potential release blocker
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
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.
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.