This is an archive of the discontinued LLVM Phabricator instance.

[llvm-cov] Allow multiple remaps in --path-equivalence
AbandonedPublic

Authored by tcamin on Jun 29 2021, 12:11 PM.

Details

Reviewers
keith
Summary

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.

Diff Detail

Event Timeline

tcamin requested review of this revision.Jun 29 2021, 12:11 PM
tcamin created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJun 29 2021, 12:11 PM
tcamin updated this revision to Diff 356161.Jul 2 2021, 6:13 AM
vsk added a subscriber: vsk.Jul 2 2021, 9:23 AM

Hi, could you say a little bit about the use case(s) for this?

Also, how would multiple path remaps interact with each other?

tcamin added a comment.Jul 2 2021, 2:03 PM

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

keith added a comment.Jul 9 2021, 10:13 AM

Can you add a test for this? Best if it encodes the multiple remapping interactions above as well

vsk added a comment.Jul 12 2021, 10:08 AM

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.

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?

tcamin updated this revision to Diff 366445.Aug 14 2021, 12:27 PM

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.

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.

tcamin updated this revision to Diff 366452.Aug 14 2021, 1:25 PM
  • Allow multiple remaps in --path-equivalence
  • Avoid creating a default constructed value
tcamin updated this revision to Diff 366519.Aug 15 2021, 12:14 PM

Fix formatting

vsk added a comment.Aug 24 2021, 1:56 PM

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

Herald added a project: Restricted Project. · View Herald TranscriptMay 30 2023, 9:17 AM

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?

tcamin updated this revision to Diff 534521.Jun 26 2023, 6:33 AM

I added some tests and updated the docs

tcamin updated this revision to Diff 534577.Jun 26 2023, 8:39 AM

Fix test

tcamin updated this revision to Diff 535359.Jun 28 2023, 6:14 AM

Fix test

tcamin updated this revision to Diff 535710.Jun 29 2023, 4:02 AM
This comment was removed by tcamin.
tcamin updated this revision to Diff 535733.Jun 29 2023, 5:16 AM

Use --binary when generating patch

tcamin abandoned this revision.Jul 7 2023, 7:59 AM

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