[PATCH] D148757: [clang] Follow user-provided order for prefix map

Gulfem Savrun Yeniceri via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 19 17:06:57 PDT 2023


gulfem added a comment.

In D148757#4282002 <https://reviews.llvm.org/D148757#4282002>, @MaskRay wrote:

> Can you add example options in the description and say how this patch is going to change it?
>
> I think `std::map` is intended so that for `-f*-prefix-map` values, if both `a/b=...` and `a/b/c=...` match an input path, the longest wins, not the latest wins.

We discovered the issue in the context of supporting source-based code coverage in the Pigweed project.
The project provides two `-ffile-prefix-map` paths that can impact coverage: 
https://cs.opensource.google/pigweed/pigweed/+/main:pw_build/BUILD.gn;l=251-256

1. `-ffile-prefix-map=../= ` to remove the relative path from the build directory to the root
2. `-ffile-prefix-map==out/` to prepend out/ to any unmatched files

If the user-specified order is applied, 1) should be applied, but in this case 2) is applied because the std::map iteration order is not the same of the insertion order.
Applying 2) appends `out` to beginning of file paths in coverage mapping records.

The question that we need to answer is whether following the user-specified order for `-f*-prefix-map` is the expected behavior.
If that's the case, `Clang` does not follow that.
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CoverageMappingGen.cpp#L1653


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148757/new/

https://reviews.llvm.org/D148757



More information about the cfe-commits mailing list