Promote coverage_common.instrumented_files_info.coverage_support_files to a public API

[UebelAndre]

Description of the feature request:

Could coverage_common.instrumented_files_info.coverage_support_files be promoted to a public API?

What underlying problem are you trying to solve with this feature?

Trying to get coverage working in rules_rust lead to the discovery of coverage_common.instrumented_files_info.coverage_support_files which I wanted to use to add llvm-cov and llvm-profdata to the coverage post-processing action but couldn't because it was a private API. I don't think these binaries should be runfiles of the test binary being defined in the rule, instead, I'd like to some how add them only to actions that will be running coverage. This field seems appropriate since the tools are indeed support files.

Which operating system are you running Bazel on?

Linux, MacOS

What is the output of bazel info release?

release 6.2.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

https://bazelbuild.slack.com/archives/CA31HN1T3/p1686230133034699 is the slack conversation that spawned this request.

[c-mita]

Would you also need coverage_environment and metadata_files? The latter is easy enough, but the former is really tied into collect_coverage.sh and collect_cc_coverage.sh (via _collect_coverage and _collect_cc_coverage).

I've always considered those scripts somewhat as "internal magic", but I'm aware that some people seek to override them, and I think we need to formalise things somewhat before I open up coverage_environment.

Any thoughts on this @fmeum ?

[UebelAndre]

Formalizing this would be great! I feel coverage in general is internal magic and it’d be fantastic to be able to have well defined contracts where I can insert my own coverage tooling and hand off intermediate files for Bazel to process and combine into the larger report

[fmeum]

@c-mita I agree that coverage_environment is too heavily tied to collect_cc_coverage.sh implementation details to open up.

metadata_files seems benign and generally useful enough. How about opening up just this attribute and cherry-picking that change to 6.3.0? Then we could do a survey of what exactly is missing for full coverage support for the remaining popular languages.

[c-mita]

I think that's ok, although I'm not sure how useful it is on its own right now.
I have an internal change to do this, pending review.

[c-mita]

The metadata_files parameter is exposed at HEAD (ef54ef5).
#18838 is a PR to pick the required change(s) onto 6.3.0.

[comius]

@c-mita please triage

[c-mita]

I'm closing this for now; one parameter has already been exposed that can actually achieve the same thing.

I would much rather pursue follow ups to https://docs.google.com/document/d/1JP-9pjiRBHmepgFzBI-U9G2nAzCWK5YoemGVVKmQsBM/ then ad-hoc incremental changes without a larger vision.