C/C++ coverage with hermetic llvm/clang toolchain configuration issue

fitzner commented 2 years ago

Description of the bug:

When Bazel will be used with a hermetic llvm/clang toolchain there are some issues to configure the tools needed for C/C++ coverage runs. It seems that the coverage environment get their tool path information via String llvmCov = toolchain.getToolPathStringOrNull(Tool.LLVM_COV); This use a deprecated mechanism to configure the tool paths [4] without a support of referencing tools/artifacts from the WORKSPACE (path: Location of the tool; Can be absolute path (in case of non hermetic toolchain), or path relative to the cc_toolchain's package.). In our case we have to override the env variable to point to the right tool path to get it to run.

coverage --test_env=COVERAGE_GCOV_PATH=external/toolchains_cc_clang.cc_configure.cc_clang/usr/local/bin/llvm-profdata
coverage --test_env=LLVM_COV=external/toolchains_cc_clang.cc_configure.cc_clang/usr/local/bin/llvm-cov

When a binwrapper (e.g. located relative to the cc_toolchain's package) will be used, there is the problem to determine the right path inside the wrapper e.g. external/toolchains_cc_clang.cc_configure.cc_clang/usr/local/bin/llvm-cov especially when Bzlmod will be used in different modes (e.g. bazel_dep, local_path_override).

What needs to be fixed The tools used by Bazel coverage can be configured via action_config [1] and by using the ToolInfo that supports an individual artifact reference [2]. The coverage environment retrieve their tools by featureConfiguration.getToolPathForAction(actionName); instead of the tool_paths [3]

[1] https://github.com/bazelbuild/bazel/blob/b9ffc16b94c1ee101031b0c010453847bdc532d1/tools/cpp/cc_toolchain_config_lib.bzl#L488 [2] https://github.com/bazelbuild/bazel/blob/b9ffc16b94c1ee101031b0c010453847bdc532d1/tools/cpp/cc_toolchain_config_lib.bzl#L435 [3] https://github.com/bazelbuild/bazel/blob/b9ffc16b94c1ee101031b0c010453847bdc532d1/src/main/java/com/google/devtools/build/lib/rules/cpp/CppHelper.java#L203 [4] https://github.com/bazelbuild/bazel/blob/8994250e9d610fe47cf6d5fcde4e5cb2b83eec6c/tools/cpp/cc_toolchain_config_lib.bzl#L408

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

You need a hermetic llvm toolchain to reproduce the issue.

bazel coverage -s --config host_clang //libs/foo/test/unit:foo_test

In this case you need a llvm/clang platform configuration as your host environment to work with a hermetic toolchain.

Configuration in your .bazelrc file

build:host_clang --host_platform=//:host_platform_clang

build --java_runtime_version=remotejdk_11
build --test_output=all

coverage --experimental_use_llvm_covmap
coverage --experimental_generate_llvm_lcov
coverage --cache_test_results=no

Which operating system are you running Bazel on?

Linux

DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"

What is the output of `bazel info release`?

release 5.1.1

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

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?

No response

github-actions[bot] commented 1 year ago

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

fmeum commented 1 year ago

@c-mita This does still seem relevant.

bazelbuild / bazel