Charles Mita

I'm pretty sure this will break something, at least internally; coverage flags in our toolchains are predicated on the presence of the "gcov_gcno_file" variable (although I don't think this is...

Basically, there needs to be another way of entering this branch https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/CompileBuildVariables.java;l=372 I am pretty sure the actual value doesn't matter and nobody depends on it, only its presence.

It depends on the rules in question. With something like `cc_test`/`cc_binary`, building with `--collect_code_coverage` will produce instrumented binaries, but the coverage data will not be gathered into a single location,...

There are currently no plans to add XML output support to Bazel; it may get some consideration in the future, but it would likely be just plugging in the genhtml...

I'm re-opening this because of the discussion I started here: https://github.com/bazelbuild/bazel/discussions/19144

No. I don't think Bazel will ever "operate" on or with XML files (it's not a good format for cross-language operations, merging across multiple runs, etc). It's possible that we...

> If needed, users can configure the loglevel by wrapping the CoverageOutputGenerator jar into a java_binary with appropriate jvmopts I don't think this is a good way to configure logging...

Yes, although I might need to review (or actually formalize) the process first. There's a long standing issue re. provenance (https://github.com/bazelbuild/bazel/issues/15459).

Created https://github.com/bazelbuild/bazel/pull/22275 manually

Nothing in particular; I have a dormant proposal https://github.com/bazelbuild/proposals/pull/351 that would, possibly, mean we wouldn't have to depend on shell scripts and rule authors could provide buildable executables to perform...