Limit coverage to requested files

[keith]

Bazel provides COVERAGE_MANIFEST which is a file we can pass through to
llvm-cov to limit the files that we produce coverage for. Using this
revealed the path-equivalence was backwards because we're using the
coverage prefix map to disable absolute paths in code coverage info,
but llvm-cov operates on absolute paths, so we have to remap the . in
the coverage data to the full path so that llvm-cov understands the
relative paths (which it absolutizes internal) from the manifest file.
This feels a bit weird and ideally it could operate entirely on these
relative paths instead.

This has the side effect of excluding files that aren't part of bazel
sources, which fixes #1466

This should also improve interaction with --instrumentation_filter.

[UebelAndre]

This file feels a bit cryptic to me. I'm happy to hear it's working but don't know enough about what it's doing to think about how to test it. Could this potentially be something that's replaced with a rust_binary? I would imagine the use of bash here adds an unnecessary requirement to windows hosts and also makes testing just a bit harder to author.

[keith]

Currently with bazel's infra that reads this file I don't think we have a choice, unless we add a custom test runner which we talked about briefly on the other PR I think. It's also bash so realistically I guess it won't work on windows either way until bazel becomes more flexible for coverage.

I wonder if we could write an integration test that could transition on coverage and depend on a rust_test and validate the coverage file contents 🤔

[keith]

Note as far as this change goes the important part is limiting the files to the ones bazel tells us. The order argument was wrong in the first place it was just being ignored until we started limiting the file.

[scentini]

I wonder if we could write an integration test that could transition on coverage and depend on a rust_test and validate the coverage file contents

This should be easily doable.

I would very much like to
a) have tests for coverage in general before declaring it supported, as it is hard to see what is being fixed here; or
b) make it guarded by an experimental flag as long as a) is not the case.

[krasimirgg]

The fixes look good, +1 to coming up with coverage tests robust enough to be able to verify fixes like these (possibly as follow-ups).

[fmorency]

I tested my project, and everything worked as expected. Thanks a lot 👍🏻

[keith]

I tried to spike out a quick test, it doesn't seem like there is any way to access the coverage.dat file from dependencies of a test, I was envisioning something like:

rust_test(
    name = "foo",
...
)

coverage_validation_test(
     name = "foo.coverage_validation",
     target = "foo",
)

but in this test's implementation I don't see a way to get my hands on that file to do something with it