Enable code coverage on windows for C++ using clang. by KrishnaM256 · Pull Request #26594 · bazelbuild/bazel

KrishnaM256 · 2025-07-21T09:59:39Z

Summary

When running bazel coverage on Windows, users often encounter errors as described in #18839 and #15835, including the %1 is not a valid Win32 application. message.

This PR resolves those issues by:

Adding a fallback mechanism to correctly locate the coverage script.
Introducing a .bat wrapper for the collect_coverage.sh script, which addresses the Win32 application error.

With these changes, seamless C++ code coverage collection on Windows using Clang is now enabled.

Why is this needed?

These improvements allow Bazel to collect and generate code coverage reports inside _cc_coverage.dat file located at COVERAGE_DIR directory for C++ targets on Windows using Clang, streamlining the workflow and reducing manual troubleshooting for users on this platform.

Closes #15835 and #6374.

Implementation Details

Follow the official Windows troubleshooting guide and set the BAZEL_SH environment variable as recommended.

Add the following flags to your .bazelrc to configure coverage collection with LLVM tools:

build --experimental_generate_llvm_lcov
test --test_env=BAZEL_SH
test --test_env=LLVM_PROFDATA="C:/Program Files/LLVM/bin/llvm-profdata.exe"
test --test_env=LLVM_COV="C:/Program Files/LLVM/bin/llvm-cov.exe"
test --test_env=GCOV_COVERAGE=0
coverage --experimental_fetch_all_coverage_outputs

Ensure that:
- The Windows environment variable BAZEL_SH is set to the path of your shell (e.g., MSYS2 or Git Bash).
- Paths to llvm-profdata.exe and llvm-cov.exe are correct for your setup.

Additional Notes

After applying these changes, running bazel coverage on C++ targets with Clang on Windows should work as expected, and coverage reports should be generated without manual intervention.
See #15835 for additional context and user reports related to these issues.

…xecute init_gcov otherwise dont

fmeum · 2025-07-21T11:36:10Z

src/main/java/com/google/devtools/build/lib/analysis/starlark/StarlarkRuleClassFunctions.java

-                    .value(labelCache.get(toolsRepository + "//tools/test:collect_coverage")))
+                    .value(labelCache.get(toolsRepository + 
+                        (OS.getCurrent() == OS.WINDOWS ? 
+                            "//tools/test:collect_coverage_wrapper" : 


It would be cleaner to keep the same label here and instead make it an alias with a select on @platforms//os:windows in the BUILD file.

Thank you for the suggestion! That sounds like a cleaner approach. I’ll update the PR to use an alias with a select statement in the BUILD file as recommended.

fmeum · 2025-07-21T11:40:16Z

tools/test/collect_coverage_wrapper.bat

+:: ==============================================================================
+@echo off
+setlocal
+%BAZEL_SH% "%~dp0collect_coverage.sh" %*


Instead of crafting a custom wrapper, could you try making the collect_coverage target an sh_binary instead of a filegroup? That rule already has the necessary logic to create a launcher binary on Windows which honors BAZEL_SH etc.

Switching the collect_coverage target to an sh_binary makes sense, and I agree it would simplify the setup on Windows. I’ll update the PR to use sh_binary instead of a filegroup and test to ensure that it works as expected with BAZEL_SH.

If I switch from filegroup to sh_binary, I encounter the following error due to the requirement that the target must produce exactly one file:
'@bazel_tools//tools/test:collect_coverage' must produce a single file because of the singleArtifact() check.

If I remove or comment out the singleArtifact() line, Bazel crashes with a NullPointerException further down in the build.

Given these constraints, would you recommend using an alias instead, or is there another preferred approach to work around this limitation?

For additional context:

When collect_coverage is a filegroup, building //tools/test:collect_coverage outputs only tools/test/collect_coverage.sh.

When I change it to an sh_binary, building the same target produces:

tools/test/collect_coverage.sh

bazel-out/x64_windows-fastbuild/bin/tools/test/collect_coverage

bazel-out/x64_windows-fastbuild/bin/tools/test/collect_coverage.exe

It seems like the multiple outputs from sh_binary are conflicting with the single file requirement

fmeum · 2025-07-21T11:41:20Z

tools/test/windows/tw.cc

  }

  (void)result->Absolutize(cwd);
+  if (!IsReadableFile(*result)) {


This fallback shouldn't be necessary - could you share the error you see if you don't add it?

You can refer to issues #18839 and #15835 for more details—I encounter the exact same error: The system cannot find the file specified. Let me know if you need any additional context!

If you address the other comments and add an integration test that runs on Windows (you could also just drop the no-windows tag on the existing coverage tests), I can look into the root cause of the failure without this fallback.

Thank you for the guidance! I’ll address the other comments and update the PR to include an integration test that runs on Windows. Once that’s done, I’ll let you know so you can investigate the root cause of the failure without the fallback.

Hello @fmeum, I’ve removed the fallback, could you please review the changes and let me know if there are any other modifications needed?

I started a parallel PR that adds support for multiple files in collect_coverage. There's still one issue left that I need to debug, but once that's done, you should be able to base your PR on it.

Oh nice, that’s great!

The PR now passes CI and includes an updated integration test that you can use as the basis for getting the others to pass.

Thanks! Great to hear the PR passes CI. I’ll use the updated integration test as a reference to get the remaining tests passing.

KrishnaM256 and others added 3 commits July 20, 2025 18:58

fixing code coverage on windows

8311295

using already defined uses_gcov function to check if uses gcov then e…

d20e37a

…xecute init_gcov otherwise dont

Merge branch 'bazelbuild:master' into master

50a33c3

KrishnaM256 marked this pull request as ready for review July 21, 2025 10:35

KrishnaM256 requested review from a team and lberki as code owners July 21, 2025 10:35

KrishnaM256 requested review from mai93 and removed request for a team July 21, 2025 10:35

github-actions bot added team-Configurability platforms, toolchains, cquery, select(), config transitions awaiting-review PR is awaiting review from an assigned reviewer labels Jul 21, 2025

KrishnaM256 marked this pull request as draft July 21, 2025 10:35

KrishnaM256 and others added 4 commits July 21, 2025 16:17

removing condition of if uses_gcov

b938807

Merge branch 'bazelbuild:master' into master

f3a8fb6

Merge branch 'master' of https://github.com/KrishnaM256/bazel

13fcef1

Merge branch 'master' of https://github.com/KrishnaM256/bazel

aa60ffb

fmeum reviewed Jul 21, 2025

View reviewed changes

KrishnaM256 added 4 commits July 22, 2025 12:39

corrected uses_gcov function and used alias with select

68413f3

corrected uses_gcov function and used alias with select

9ab83c2

using uses_gcov

bd82008

removed fallback

ac48573

KrishnaM256 requested a review from fmeum July 22, 2025 11:57

Conversation

KrishnaM256 commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why is this needed?

Implementation Details

Additional Notes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

KrishnaM256 commented Jul 21, 2025 •

edited

Loading