You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our use case for the -path-equivalence option to llvm-cov seems to be covered by the descriptive part of its command documentation, “Map the paths in the coverage data to local source file paths,” though it differs from the subsequent motivational sentence (“This allows you to generate the coverage data on one machine, and then use llvm-cov on a different machine where you have the same files on a different path.”) Our details are quite complicated (involving Rust and Cargo dependencies with duplicated files), but the problem reproduces with the natural extension of the basic example in the Source-based Code Coverage: The -path-equivalence option makes no difference to the output.
While there are tests which use the option, e.g. llvm/test/tools/llvm-cov/showExpansions.cpp and llvm/test/tools/llvm-cov/showProjectSummary.cpp, their checks don’t seem to depend on the option making a difference — and when imitating the tests manually, the option made no difference.
Steps to Reproduce
Here are the simplified steps, using the foo.cc from the documentation:
In directory Path_Equivalence, then repeated in the directory Other_Path_Equivalence:
We need the coverage data for both files mapped to source file path Other_Path_Equivalence/foo.cc. Obviously in this simplified example it makes no difference, but in our case the majority of our test coverage is in one dependency copy of the file(s) of interest, with some test coverage is in the original location.
Configuration
macOS 12.6.5 21G531 on M1 Max
Clang built from source 54fd5cf, May 12 09:31:04 2023 -0700.
The text was updated successfully, but these errors were encountered:
Our use case for the
-path-equivalence
option tollvm-cov
seems to be covered by the descriptive part of its command documentation, “Map the paths in the coverage data to local source file paths,” though it differs from the subsequent motivational sentence (“This allows you to generate the coverage data on one machine, and then use llvm-cov on a different machine where you have the same files on a different path.”) Our details are quite complicated (involving Rust and Cargo dependencies with duplicated files), but the problem reproduces with the natural extension of the basic example in the Source-based Code Coverage: The-path-equivalence
option makes no difference to the output.While there are tests which use the option, e.g. llvm/test/tools/llvm-cov/showExpansions.cpp and llvm/test/tools/llvm-cov/showProjectSummary.cpp, their checks don’t seem to depend on the option making a difference — and when imitating the tests manually, the option made no difference.
Steps to Reproduce
Here are the simplified steps, using the
foo.cc
from the documentation:In directory
Path_Equivalence
, then repeated in the directoryOther_Path_Equivalence
:In directory
Path_Equivalence
:LLVM_PROFILE_FILE="foo.profraw" ./foo
In directory
Other_Path_Equivalence
:LLVM_PROFILE_FILE="foo2.profraw" ./foo
Back in directory
Path_Equivalence
:Actual Output
The output shows both files; it does not map the path
…/Path_Equivalence
in the coverage data to the local source file path…/Other_Path_Equivalence
:Expected Output
We need the coverage data for both files mapped to source file path
Other_Path_Equivalence/foo.cc
. Obviously in this simplified example it makes no difference, but in our case the majority of our test coverage is in one dependency copy of the file(s) of interest, with some test coverage is in the original location.Configuration
macOS 12.6.5 21G531 on M1 Max
Clang built from source 54fd5cf, May 12 09:31:04 2023 -0700.
The text was updated successfully, but these errors were encountered: