bazel coverage (C++) drops data for files with the same name.
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the problem / feature request:
The generated coverage report seems to essentially treat similarly named files as the same file.
The simplistic example:
```
project_root/
test/
foo.cpp
foo.h
foo.cpp
```
Generating coverage will not show any data for `project_root/foo.cpp.`
`project_root/foo.h` and `project_root/test/foo.cpp` (if using `--instrument_test_targets`) will have data. Along with all other expected files.
The simple response to this would be "well, just rename your test files". Which, while maybe a little annoying and time consuming ***does*** solve the issue. And, that being said, i will start to do.
However, a more compelling example, if we consider a decently large enough project, it seems pretty reasonable to find two files with the same name. i.e. Something generic like connection.
It would be nice not to have to take naming of files into considering for the sake of coverage.
### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
As above, create a test named the same as the code file its testing and try to generate coverage for it under C++.
`bazel coverage `
The testing framework being used was google test, but i don't think that is important to the issue.
### What operating system are you running Bazel on?
Untuntu 20.04
### What's the output of `bazel info release`?
release 3.4.1
### Have you found anything relevant by searching the web?
Yes. GCOV itself seems to have issues with similarly named files, per https://stackoverflow.com/questions/33989326/trouble-running-gcov-with-multiple-source-files-of-the-same-name
But this doesn't seem to be the issue as i far as i can determine by looking at the intermediate results with `--experimental_fetch_all_coverage_outputs`
From the extent i've looked into this, i think simply giving unique names to the files generated might solve the issue? i.e the `X.pic.gcda.gcov.json.gz` files. Maybe by prefixing with path information?
Contributor guide
Assessment
This issue has not been assessed yet.