Add path remapping with -coverage-prefix-map to coverage data #32175
Conversation
keith
force-pushed
the
ks/coverage-relative
branch
from
84bad2f to
9f0839b
Compare
|
@vedantk mind checking up on this one again when you have a chance? |
|
I need to check up on our conversation on cfe-dev. Petr raised a point about existing users of -debug-prefix-map + -profile-coverage-mapping: if e.g. they've got an Xcode project set up this way, the IDE integration may rely on being able to produce a coverage report from anywhere on the filesystem, which this change would break. So I think we'll need to add a new flag to swift to change this behavior. |
|
I think regardless of a new flag or not Xcode would have to be updated to support these bundles generated from anywhere (assuming it wanted to support this or not) I'm happy to add a new flag here, but I did think this one was "more ok" since unlike clang Swift feels pretty conservative with new flags and instead tries to do the "right thing" in most of these cases, which I would argue this is. |
|
Yep, that's the issue -- Xcode doesn't support coverage mappings with relative paths today, and I'm not sure when (or if) it will. So I think we should try not to break coverage workflows that use -debug-prefix-map, esp. considering non-xcode workflows that hand-roll llvm-cov commands can have the same issue. Introducing a new driver option isn't ideal, but if part of its contract explicitly states that all paths in compiled objects are going to be remapped, hopefully that'll be the last one.. |
Previously the path to covered files in the __LLVM_COV / __llvm_covmap section were absolute. This made remote builds with coverage information difficult because all machines would have to have the same build root. This change uses the values for `-coverage-prefix-map` to remap files in the coverage info to relative paths. These paths work correctly with llvm-cov when it is run from the same source directory as the compilation, or from a different directory using the `-path-equivalence` argument. This is analogous to this change in clang https://reviews.llvm.org/D81122
keith
changed the title
keith
force-pushed
the
ks/coverage-relative
branch
from
9f0839b to
1b77448
Compare
|
@vedantk I've updated this change with |
This is analogous to this change in Driver.cpp swiftlang/swift#32175
This is analogous to this change in Driver.cpp swiftlang/swift#32175
|
@swift-ci smoke test and merge |
|
I think that this is responsible for a Windows regression: https://ci-external.swift.org/job/oss-swift-windows-x86_64-vs2019/1737/ |
This should ship in Swift 5.3.x swiftlang/swift#32175
This should ship in Swift 5.3.x swiftlang/swift#32175
Previously the path to covered files in the __LLVM_COV / __llvm_covmap
section were absolute. This made remote builds with coverage information
difficult because all machines would have to have the same build root.
This change uses the values for
-coverage-prefix-mapto remap files inthe coverage info to relative paths, or any other remapping that was
passed. These paths work correctly with llvm-cov when it is run from
the same source directory as the compilation, or from a different
directory using the
-path-equivalenceargument.This is analogous to this change in clang https://reviews.llvm.org/D81122