macOS C++ coverage support doesn't cover lines in header files

[phst]

Description of the problem / feature request:

Even with workarounds for https://github.com/bazelbuild/bazel/issues/10457 in place, bazel coverage doesn't produce coverage instrumentation for inline functions defined in header files.

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

BUILD file:

cc_test(
    name = "test",
    srcs = ["test.cc"],
    deps = [":lib"],
)

cc_library(
    name = "lib",
    srcs = ["lib.cc"],
    hdrs = ["lib.h"],
)

lib.h:

#include <iostream>
inline void InlineFunction() {
  std::cout << "inline function" << std::endl;
}
extern void NotInlineFunction();

lib.cc:

#include "lib.h"
#include <iostream>
void NotInlineFunction() {
  std::cout << "not inline function" << std::endl;
}

test.cc:

#include "lib.h"
int main() {
  InlineFunction();
  NotInlineFunction();
}

Then, run

bazel --nohome_rc --nosystem_rc --noworkspace_rc --bazelrc=/dev/null coverage \
  --test_env=VERBOSE_COVERAGE=1 --test_env=GCOV_PREFIX_STRIP=10 \
  --test_output=all --nocache_test_results //:test

The GCOV_PREFIX_STRIP is for https://github.com/bazelbuild/bazel/issues/10457.

The resulting coverage.dat then has contents for lib.cc, but not lib.h.

Te file _cc_coverage.gcov, which lcov_merger uses as source file, has entries for lib.cc and ./lib.h (note the ./ in ./lib.h). My guess is thus that https://github.com/bazelbuild/bazel/blob/5.0.0/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/Coverage.java#L77 shouldn't use plain string comparison, but normalize the filenames first.

What operating system are you running Bazel on?

macOS 12.2.1

What's the output of bazel info release?

release 5.0.0-homebrew

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

Nothing (not in a Git repository)

Have you found anything relevant by searching the web?

https://github.com/bazelbuild/bazel/issues/10457 is somewhat related (albeit a bit pessimistic; coverage on macOS does work in general), but doesn't seem to touch on this specific bug.

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

Logs

[keith]

can you test with the experimental LLVM cov flag and see if that works for your case?

[phst]

Sorry, what's the "experimental LLVM cov flag"?

[keith]

https://docs.bazel.build/versions/main/command-line-reference.html#flag--experimental_use_llvm_covmap

[phst]

At least on my machine that flag breaks coverage entirely, with similar symptoms as https://github.com/bazelbuild/bazel/issues/14970 (attempts to call gcov merge instead of llvm-cov merge).

[github-actions[bot]]

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 14 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.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[fmeum]

This looks similar to https://github.com/bazelbuild/bazel/issues/19338.

@phst Are you still seeing this? See https://github.com/bazelbuild/bazel/pull/19349 for a PR with tests for this.