[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