Stop listing .gcno files as outputs when using LLVM coverage map format

[brentleyjones]

When using --experimental_use_llvm_covmap, no .gcno files are output. By listing them as outputs there is a mismatch between expected and actual outputs. Bazel will create these empty files after the action is run, but they non-deterministically get counted in the Action outputs, which can lead to cache misses on subsequent runs.

[fmeum]

Cc @c-mita

[brentleyjones]

@bazel-io flag

[iancha1992]

@bazel-io fork 7.2.0

[c-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 the case for Bazel's default toolchain), which is passed when these files are declared.

I think more of a refactor is needed before a change like this can be made.

[brentleyjones]

What compromise can I make to get this over the finish line? I would really like this to get into 7.2.0, as it's a big source of cache misses for us.

[c-mita]

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.

[brentleyjones]

So I can pass down an empty string when isCodeCoverageEnabled, and that should satisfy it? If so, I can add a comment on why we are doing that, and call it good.

[brentleyjones]

@c-mita I made a change. LMK what you think.

[c-mita]

I think this is "fine".

We should probably simplify things and remove the passing around of the, possibly null, gcnoFile Artifact since, AFAICT, the actual value of this variable isn't important. But that's a riskier change that I can follow up on later.

We should also probably rename the variable in the future (another round of fun) and actually document it.