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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
