Closed wiegandm closed 6 years ago
Thank you @wiegandm for the report.
This is indeed a mistake, I don't remember why I initialized the default value to -1
. I'll fix that and create a new release.
However, I think that codecov
should also handle that kind of input as lcov
is handling them:
https://github.com/linux-test-project/lcov/blob/master/bin/lcov#L1686-L1691
I'll fix that and create a new release.
Thank you!
However, I think that codecov should also handle that kind of input as lcov is handling them
Indeed, this is what I would have expected. But I am not familiar with codecovs rationale for their behavior and I do not know about the file format to pass a judgement here.
@wiegandm here you are : 1.3.1 Fell free to post any other issue you might see
here you are : 1.3.1
Confirmed, undocumented lines are now counted as 0
and lcov
no longer complains. :tada:
Thanks a lot for this very useful tool!
I noticed that the
output_print_lcov
method will produce negative execution counts in thelcov
output format when it encounters an undocumented object:https://github.com/psycofdj/coverxygen/blob/ce7e1534b4c7b2bc91d8997483c87ddd2718f5a2/coverxygen/__init__.py#L226
This results in output like the following:
lcov (at least in version 1.13) will process the file properly, but complains:
The service
codecov.io
on the other hand processes the output, but counts negative counts as covered, leading to an incorrect 100% coverage.Replacing all counts of
-1
in the output with0
(e.g. withsed -i -e 's/,-1$/,0/g' <outputfile>
) causes the warning to disappear from thelcov
andgenhtml
output while still producing the correct coverage report.More importantly (at least for me), submitting the file with the counts set to
0
instead of-1
tocodecov.io
results in the results being parsed correctly and the coverage information being available throughcodecov.io
.