LLVM coverage does not process headers which are included via a search path

[quuuuux]

Description of the bug:

When using --experimental_use_llvm_covmap and --experimental_generate_llvm_lcov, header files are only processed if they are included via a relative path (#include "include/foo.h") rather than a search path (includes = ["include"] followed by #include <foo.h> or #include "foo.h").

Which category does this issue belong to?

C++ Rules

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

A minimal reproducer can be found at https://github.com/quuuuux/bazel_clang_coverage_reproducer. Flipping https://github.com/quuuuux/bazel_clang_coverage_reproducer/blob/master/test.cc#L3 from 1 to 0 demonstrates that the issue goes away if the header is included via a relative path.

Which operating system are you running Bazel on?

Ubuntu 22.04 LTS

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 HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

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

Via search path:

cat bazel-out/_coverage/_coverage_report.dat
SF:lib.cc
...
end_of_record
SF:works.h
...
end_of_record

Via relative path:

cat bazel-out/_coverage/_coverage_report.dat
SF:include/doesntwork.h
...
end_of_record
SF:lib.cc
...
end_of_record
SF:works.h
...
end_of_record

[comius]

cc @c-mita

[comius]

friendly ping @c-mita, please do a quick triage (even if you don't have time to investigate)

[c-mita]

I suspect this is because the filename in the raw coverage data (which I'm guessing is "doesntwork.h") doesn't line up with the filename as known by the rule ("include/doesntwork.h"). The contents of coverage data are usually clipped against a manifest file.

But that's a guess; I've not confirmed how LLVM names the included header in this situation. It would be problematic though, and I'm not sure what the best way to proceed would be.