Uncovered new line at end of file

[davidgrayston]

Q	A
php-code-coverage version	9.1.4
PHP version	7.4
Driver	Xdebug
Xdebug version	2.9.6
Installation Method	Composer
Usage Method	PHPUnit
PHPUnit version	9.3.7

Since upgrading from PHPUnit 9.2, new lines at the end of files are being reported as uncovered in the XML report, e.g.

<line num="32" type="stmt" count="0"/>

It seems to be caused by the removal of this workaround (as reinstating it fixes the clover report): d9c9b7b

The report is being consumed by SonarCloud - should the last line of files be ignored regardless of the uploaded XML report? If that's the case, I can raise an issue with SonarCloud.

[sebastianbergmann]

Thank you for your report.

Please provide a minimal, self-contained, reproducing test case that shows the problem you are reporting.

Without such a minimal, self-contained, reproducing test case I will not be able to investigate this issue.

[davidgrayston]

I've created a small demo here: https://github.com/davidgrayston/phpunit-demo/tree/master/php-code-coverage-799

You can run cd php-code-coverage-799 and composer demo to see a report diff

[sebastianbergmann]

CC @dvdoug @derickr

[derickr]

PHP reports a line "14" for the implicit return at the end of a file. This is not a bug in php-code-coverage or Xdebug:

derick@singlemalt:/tmp$ php -dvld.active=1 Demo.php 
Finding entry points
Branch analysis from position: 0
1 jumps found. (Code = 62) Position 1 = -2
filename:       /tmp/Demo.php
function name:  (null)
number of ops:  3
compiled vars:  none
line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
    3     0  E >   NOP                                                      
   14     1        EXT_STMT                                                 
          2      > RETURN                                                   1

branch: #  0; line:     3-   14; sop:     0; eop:     2; out0:  -2
path #1: 0, 
Class DG\Demo:
Function hello:
Finding entry points
Branch analysis from position: 0
1 jumps found. (Code = 62) Position 1 = -2
filename:       /tmp/Demo.php
function name:  hello
number of ops:  6
compiled vars:  none
line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
    9     0  E >   EXT_NOP                                                  
   11     1        EXT_STMT                                                 
          2      > RETURN                                                   'hello'
   12     3*       EXT_STMT                                                 
          4*       VERIFY_RETURN_TYPE                                       
          5*     > RETURN                                                   null

branch: #  0; line:     9-   12; sop:     0; eop:     5
path #1: 0, 
End of function hello

End of class DG\Demo.

[davidgrayston]

The introduction of this line in the report has affected coverage reporting on SonarCloud - should I follow this up with SonarCloud linking to this issue?

[davidgrayston]

Link for reference https://community.sonarsource.com/t/php-coverage-uncovered-new-line-at-end-of-file/29888

[davidgrayston]

I understand the issue is now closed (so I apologise for replying), but I thought it's worth mentioning that setting processUncoveredFiles="false" results in the line being covered:

<line num="14" type="stmt" count="1"/>

I don't fully understand why this is happening - perhaps the file is loaded when gathering uncovered files (so executes the line at the end of the file), but not loaded again by the autoloader when running the tests.

[dvdoug]

Hi @sebastianbergmann

Notwithstanding the analysis by @derickr (thanks!), I think this should be reopened. I feel this is one of those cases where being technically correct is not the best kind of correct. There are few overlapping reasons:

• The fact there that the PHP interpreter thinks there is an implicit return on line 14 is completely unintuitive. It's an empty line! Every other empty line in the file is considered non-executable.
• The fact that the coverage results for the same file are different depending on what would seem to be a completely unrelated configuration setting processUncoveredFiles tips the balance in favour of adding code to ensure consistency for me. This isn't simply a case of Xdebug and PHPDBG disagreeing on what a covered line is, this is a line showing as uncovered that developers are not able to exercise in their tests at all
• The fact that the HTML report explicitly removes the empty line when producing its line by line output (https://github.com/sebastianbergmann/php-code-coverage/blob/master/src/Report/Html/Renderer/File.php#L1008) means there is inconsistency in results between report formats
• The fact that despite line 14 being shown as uncovered in the clover report, 100% line coverage is still being claimed by all of the other reports. There's an inconsistency in the maths here. The clover report itself even claims there are 13 lines, but then outputs data for line 14. That...doesn't seem right.

<?xml version="1.0" encoding="UTF-8"?>
<coverage generated="1598109988">
  <project timestamp="1598109988">
    <file name="C:\tmp\phpunit-demo\php-code-coverage-799\src\Demo.php">
      <class name="DG\Demo" namespace="global">
        <metrics complexity="1" methods="1" coveredmethods="1" conditionals="0" coveredconditionals="0" statements="1" coveredstatements="1" elements="2" coveredelements="2"/>
      </class>
      <line num="9" type="method" name="hello" visibility="public" complexity="1" crap="1" count="1"/>
      <line num="11" type="stmt" count="1"/>
      <line num="14" type="stmt" count="0"/>
      <metrics loc="13" ncloc="13" classes="1" methods="1" coveredmethods="1" conditionals="0" coveredconditionals="0" statements="1" coveredstatements="1" elements="2" coveredelements="2"/>
    </file>
    <metrics files="1" loc="13" ncloc="13" classes="1" methods="1" coveredmethods="1" conditionals="0" coveredconditionals="0" statements="1" coveredstatements="1" elements="2" coveredelements="2"/>
  </project>
</coverage>

Since every other part of the codebase (and developer expectation) seems to think that example file only has 13 lines, I think the clover report should be adjusted to match and strip off the last line of a file if it's empty to match.

[sebastianbergmann]

I think the clover report should be adjusted to match and strip off the last line of a file if it's empty to match.

I would like to avoid handling this in the report(s) and rather clean up the data.

[derickr]

It should be fixed in PHP.

[derickr]

this is a line showing as uncovered that developers are not able to exercise in their tests at all

That's not true though, the line should show as covered if the file is included.