New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix source filename handling when using --use-gcov-files #146

Merged
merged 1 commit into from Jan 20, 2018

Conversation

Projects
None yet
2 participants
@mayeut
Contributor

mayeut commented Sep 1, 2016

gcov documentation states that gcov should be run with the current directory the same as that when you invoked the compiler.
It makes sense to handle source filename resolution using this information.

Fixes #145

@mayeut mayeut force-pushed the mayeut:patch-nested-existing branch from 3c44fe9 to d397e05 Sep 1, 2016

@mayeut mayeut force-pushed the mayeut:patch-nested-existing branch 6 times, most recently from 6abd63d to f571811 Jan 8, 2018

@mayeut mayeut force-pushed the mayeut:patch-nested-existing branch 3 times, most recently from 8b563d9 to 7adc3bb Jan 16, 2018

@mayeut

This comment has been minimized.

Contributor

mayeut commented Jan 17, 2018

@latk, if you get some time, will you please review this one. It's rebased on latest master (232fb11).

@latk latk added the needs review label Jan 18, 2018

@latk

This comment has been minimized.

Member

latk commented Jan 18, 2018

I've looked at this PR a couple of times and still don't understand it. There's a quite complicated test case for a change of three lines of code. While I'm sure this represents a good improvement, I'm not seeing the big picture here.

Could you give me an explanation on what the problem is, and how the test case represents this problem? It would be extremely helpful if you can walk me through the various file paths and what gcovr will do with them under your change. We can then later edit this explanation into a README for the test case.

Though not strictly required, I prefer to merge a change only if I understand what I'm doing :D

@mayeut

This comment has been minimized.

Contributor

mayeut commented Jan 18, 2018

The new test nested2-use-existing is built exactly the same way as nested2 test. The only difference is that gcov is ran outside of gcovr following gcov documentation (gcov should be run with the current directory the same as that when you invoked the compiler.) rather than letting gcovr manage gcov invocation.

First a little sample of what happens without the patch.
Output for nested2-use-existing:

------------------------------------------------------------------------------
                           GCC Code Coverage Report
Directory: subdir
------------------------------------------------------------------------------
File                                       Lines    Exec  Cover   Missing
------------------------------------------------------------------------------
B/main.cpp                                     9       9   100%   
------------------------------------------------------------------------------
TOTAL                                          9       9   100%
------------------------------------------------------------------------------

Output for nested2:

------------------------------------------------------------------------------
                           GCC Code Coverage Report
Directory: subdir
------------------------------------------------------------------------------
File                                       Lines    Exec  Cover   Missing
------------------------------------------------------------------------------
A/C/D/file6.cpp                                4       3    75%   4
A/C/file5.cpp                                  4       3    75%   4
A/file1.cpp                                    4       3    75%   4
A/file2.cpp                                    7       4    57%   8,10-11
A/file3.cpp                                    9       4    44%   8,10-12,14
A/file4.cpp                                    4       3    75%   6
A/file7.cpp                                    2       0     0%   1,3
B/main.cpp                                     9       9   100%   
------------------------------------------------------------------------------
TOTAL                                         43      29    67%
------------------------------------------------------------------------------

As we can see, we're missing quite a bit of coverage information.
This comes from the way gcovr currently tries to resolve the source filename when using existing gcov files.

If we have a look at the verbose output for A/file1.cpp:

Finding source file corresponding to a gcov data file
  currdir      /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing
  gcov_fname   /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir/A/file1.cpp.gcov
               ['        -', '    0', 'Source', 'file1.cpp\n']
  source_fname None
  root         /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir
  fname        /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/file1.cpp
Parsing coverage data for file /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/file1.cpp
  Filtering coverage data for file /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/file1.cpp

We can see that gcovr is building the source filename from its current directory and the filename found in the gcov file. This results in /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/file1.cpp which is not the path of the file which gets filtered out.

Instead, gcovr shall build the source filename from the directory in which the gcov file resides in and, as it already does, the filename found in the gcov file.

If we do that, here's the verbose output for that same file:

Finding source file corresponding to a gcov data file
  currdir      /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing
  gcov_fname   /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir/A/file1.cpp.gcov
               ['        -', '    0', 'Source', 'file1.cpp\n']
  source_fname None
  root         /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir
  fname        /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir/A/file1.cpp
Parsing coverage data for file /Users/Matt/Dev/gcovr/gcovr/tests/nested2-use-existing/subdir/A/file1.cpp

This time, the source filename is resolved correctly.
Given the number of tests using existing gcov files, I added a test not to modify the previous behavior of gcovr but, if sticking to gcov documentation, it shouldn't be necessary at all. In fact, only the last line of the patch could be kept in the surrounding if source_fname is None: test.

@mayeut mayeut force-pushed the mayeut:patch-nested-existing branch 2 times, most recently from 3f64a77 to 2436567 Jan 18, 2018

@latk

latk approved these changes Jan 19, 2018

Thank you very much for the clear and thorough explanation. I understand now. This is a great improvement and seems like a very reasonable approach for resolving the path.

# let's try using the path to the gcov file as base directory
# Test before assigning not to change behavior compared to previous versions
if os.path.exists(os.path.join(os.path.dirname(data_fname), segments[-1].strip())):
fname = aliases.unalias_path(os.path.join(os.path.dirname(data_fname), segments[-1].strip()))

This comment has been minimized.

@latk

latk Jan 19, 2018

Member

Can we assign the path to some variable to avoid code duplication? E.g.

possible_gcov_path = os.path.join(...)
if os.path.exists(possible_gcov_path):
  fname = aliases.unalias_path(possible_gcov_path)

This comment has been minimized.

@mayeut

mayeut Jan 19, 2018

Contributor

Done

Fix source filename handling when using --use-gcov-files
gcov documentation states that gcov should be run with the current directory the same as that when you invoked the compiler.
It makes sense to handle source filename resolution using this information.

@mayeut mayeut force-pushed the mayeut:patch-nested-existing branch from 2436567 to b9debeb Jan 19, 2018

@latk latk merged commit 65b5486 into gcovr:master Jan 20, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@mayeut mayeut deleted the mayeut:patch-nested-existing branch Jan 20, 2018

@latk latk removed the needs review label Jan 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment