Previously the --path-equivalence parameter would allow to specify a single remap pair (coverage data path - local source file path). This patch changes this allowing to pass as many remaps as needed.
Details
Diff Detail
Unit Tests
Event Timeline
Hi, could you say a little bit about the use case(s) for this?
Also, how would multiple path remaps interact with each other?
Hi,
Thanks for taking a look at this.
Our application is split into different modules which get built as separate libraries. These libraries are prebuilt and are shared among our devs as a build cache to reduce compilation times. These libraries do not necessarily share a single map between build path and source code location and therefore we’re unable to get coverage data out all of them.
Our requirement is being able to extract coverage data when running integration tests.
Multiple remaps are evaluated in order and are not applied more than once to a file (see line 490).
Can you add a test for this? Best if it encodes the multiple remapping interactions above as well
Thanks for explaining. Would it be practical to invoke llvm-cov multiple times (once per {library, path-remap} pair)? Is the issue with this that you would have separate reports per library?
Sorry for the very late update. As far as I understood running llvm-cov multiple times would not work for us. We are trying to extract coverage from UI tests (integration tests) which are run on our iOS application. At compile time the app, to improve build times, is linked against prebuilt frameworks of our modules. We need to extract a single coverage result which covers all the source code of our app along with the source code of our separate prebuilt modules. Hope this makes sense.
- Allow multiple remaps in --path-equivalence
- Avoid creating a default constructed value
Seconding Keith's comment - please add a test.
Also, please describe the behavior change in docs/CommandGuide/llvm-cov.rst. In particular it'd help to clarify the behavior w.r.t multiple remaps. Say you have the following remaps:
/a -> /x
/a/b -> /y
Then (IIUC) a file at "/a/b/t.c" is remapped to "/x/b/t.c", not "/y/t.c", right? I think that's a surprising result, and is at least worth documenting, if not warning about.
llvm/tools/llvm-cov/CodeCoverage.cpp | ||
---|---|---|
836–849 | Warn if the number of pairs isn't even? |
We discovered another use case where we'd actually like this, we compile some modules with vfs overlays, which need 1 path remapping, and normally, which need some other remapping, in that case today I think we have to pick or choose. In this case they also all end up in the same binary, so we can't split up llvm-cov invocations
Hi! This use case is something we've run into as well. Do you have a plan to update the patch with a test case?
This revision should be closed as it has been superseded by https://reviews.llvm.org/D154223. Please refer to the updated revision for the latest changes and progress. Thank you
Warn if the number of pairs isn't even?