Use llvm-cov export to detect source files per binary
#398
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When binary contains single source file, output of `llvm-cov show` does not contain the file name. That leads to `source_file_pathname` to contain actual source code (first line of it) instead of a path. Previously, result of `find_source_files` method was used to understand if a binary is a single source: ``` source_files = find_source_files || [] … # If a single source file is used, the resulting output does not contain the file name. coverage_file.source_file_pathname = source_files.first if source_files.count == 1 ``` Though that approach won’t work for projects which contains several binaries (and then `source_files` will be a mix of files from different binaries) or when you don’t provide list of source file in configuration (it’s what `find_source_files` returns). So we either need to provide the list of files per binary or somehow get the info from profdata file. `llvm-cov export` tool exports the coverage data in JSON format and it doesn’t depend on whether there is a single source file or more in a binary. So I propose to use it and parse JSON output to get a list of source files prior to actually running `llvm-cov show` command. That makes optimizations on lines 134-138 obsolete.
|
Stack trace for |
For Xcode <= 9.2 compatibility
|
I removed |
|
I will fix the tests if the overall approach is tolerable. |
|
@blackm00n any delivery planning for this issue? |
|
@ksuther please check this PR when you have free time Small coverage decrease is caused by the introduction of |
|
Thanks for the changes! Using the JSON output definitely provides some more certainty. In the long run it looks like the way forward is xccov, but that's not something I have time to get into right now. gcov has been unused for long enough that any xccov implementation should probably drop gcov and llvm-cov and use xccov exclusively (and become slather 3). That's all hypothetical at this point :) |
|
Also, if some other people could confirm that this PR fixes their issues I'll push an update to RubyGems. |
|
@ksuther It did fix my issue |
This was referenced Jul 16, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When binary contains single source file, output of
llvm-cov showdoes not contain the file name. That leads tosource_file_pathnameto contain actual source code (first line of it) instead of a path.Previously, result of
find_source_filesmethod was used to understand if a binary is a single source:Though that approach won’t work for projects which contains several binaries (and then
source_fileswill be a mix of files from different binaries) or when you don’t provide list of source file in configuration (it’s whatfind_source_filesreturns). So we either need to provide the list of files per binary or somehow get the info from profdata file.llvm-cov exporttool exports the coverage data in JSON format and it doesn’t depend on whether there is a single source file or more in a binary. So I propose to use it and parse JSON output to get a list of source files prior to actually runningllvm-cov showcommand.That makes optimizations on lines 134-138 obsolete.