Scalar literals produce incorrect code coverage information

[DeveloperRob]

Q	A
php-code-coverage version	14.1.5+
PHP version	8.5.4
Driver	Xdebug
Xdebug version (if used)	3.5.1
Installation Method	Composer / PHPUnit PHAR
Usage Method	PHPUnit / other
PHPUnit version (if used)	13.1.7 / 13.1..8

When using a string literal to provide inline type annotations (as supported by phan for instance), then following the fix for #1029 released in 14.1.5 the string literals are showing as uncovered code. This is because:

• Xdebug does not return it as an executable line of code (as it is dead code that gets optimised out)
• ExecutableLinesFindingVisitor doesn't have any special case handling string literals (or other scalar values by themselves)
• The fix for 1029 means that lines which are considered executable but are not present at all in the coverage data from xdebug are now included

Reproducing code:

System under test:

<?php
class Foo{
    public function bar(){
        'foobar';
        return true;
    }
}

Outcome on 14.1.4:

PHPUnit 13.1.7 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.5.4 with Xdebug 3.5.1

.                                                                   1 / 1 (100%)

Time: 00:00.058, Memory: 22.00 MB

OK (1 test, 1 assertion)


Code Coverage Report:
  2026-05-04 15:14:41

 Summary:
  Classes: 100.00% (1/1)
  Methods: 100.00% (1/1)
  Lines:   100.00% (1/1)

Foo
  Methods: 100.00% ( 1/ 1)   Lines: 100.00% (  1/  1)

Outcome on 14.1.6:

PHPUnit 13.1.8 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.5.4 with Xdebug 3.5.1

.                                                                   1 / 1 (100%)

Time: 00:00.053, Memory: 22.00 MB

OK (1 test, 1 assertion)


Code Coverage Report:
  2026-05-04 15:17:29

 Summary:
  Classes:  0.00% (0/1)
  Methods:  0.00% (0/1)
  Lines:   50.00% (1/2)

Foo
  Methods:   0.00% ( 0/ 1)   Lines:  50.00% (  1/  2)

[sebastianbergmann]

Before I saw #1157 I was about to write this: are you sure this issue is still present on on main?

[DeveloperRob]

Hello @sebastianbergmann (responding to your comment on the PR itself as well),

Yes - I confirmed this to ensure my test passed (I ran the test with/without the change to ensure the test correctly failed before the change was made). While there has been quite a few changes to ExecutableLinesFindingVisitor.php compared with the 14.1.6 release, the issue is because enterNode doesn't receive expr within the Node\Stmt\Expression object (so both branches of the if are needed).

No problem in respect to your commit vs the pull-request - given the move to functions that makes sense. The only other thought I has was with the current code, it might be possible to call neater to call isAlwaysIgnored instead of my inline checks / the new isSideEffectFreeExpressionStatement. My current understanding of the code meant I was not confident that every expression (which can occur) that is on the ALWAYS_IGNORED list should be ignored however; hence not doing so, however it might be worth your consideration (as currently at least there are no classes that are side effect free expressions that are not also ignored by isAlwaysIgnored.

Thanks,
Robert