Make it possible to use llvm-cov with bazel coverage

[mkosiba]

The fact that llvm-cov and llvm-profdata are not set seems to trip up the external/bazel_tools/tools/test/collect_cc_coverage.sh script resulting in empty .dat files.

To solve the issue we implement something similar to what's done in rules_cc.

After these changes bazel coverage <test target> no longer produces empty .dat files.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[keith]

does these being host specific absolute paths affect caching? since this will have the absolute path to Xcode.app in it

[mkosiba]

yes, you're right that the coverage actions will probably be cached incorrectly. This was already the case if the GCOV env var was set, so I didn't notice. What's a good way forward here?

Looks like I can put the _get_tool_path logic into a bash script and then:

tool_paths["llvm-cov"] = "llvm-cov.sh"

That should result in a relative path being baked into the action instead of an absolute path. Do you think that'd work?

[keith]

Yea i think that would work.

I think the reason the gcov one has flown under the radar is because in apple specific (aka non-c++) tests the coverage logic is handled in rules_apple and sidesteps all of this

[mkosiba]

no worries. I think the updated version addresses this issue. If no overrides are present then the cache key contains a script which just says xcrun --run gcov/llvm-profdata/llvm-cov. Since the script is the same across machines caching should work fine.
If there are override env vars present, then as long as users set the override to the same value, they should also get cache hits.