[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

vsk added a comment. Thanks for pointing DW_AT_comp_dir out. For coverage, gating the use of relative paths on a flag sounds reasonable to me. It should also be possible to extend the .covmapping format to include something like DW_AT_comp_dir: compared to adding a flag, this would take a lot m

[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

phosek added a comment. In D95753#2534061 , @vsk wrote: > For context, the reason abspaths are used here is because users don't expect > coverage results to go missing if the build directory changes (e.g. given `cd > A; cc x.c; cd ../B; cc x.c`, the expe

[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

vsk added a comment. For context, the reason abspaths are used here is because users don't expect coverage results to go missing if the build directory changes (e.g. given `cd A; cc x.c; cd ../B; cc x.c`, the expectation is that coverage for two distinct x.c's is reported). I think it's import

[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

phosek added a comment. @vsk @davidxl I'd be interested in your opinion. I've made this change unconditionally to match the compiler behavior in cases like debug info or `__FILE__` expansion, but I'm also happy to conditionalize it on a flag (for example `-f[no]-coverage-mapping-abspath`) if yo

[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

phosek created this revision. phosek added reviewers: vsk, davidxl. phosek requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. We currently always absolutize paths in coverage mapping. This is problematic for reproducibility and it poses a prob