|
|
Hi!
I'm going to need a short reproducible case.
In this, please only include the code that has and uses the trait, and causes this issue with code overage. I don't need or want any PHP Unit test case, composer library, etc.
cheers,
Derick |
|
|
I'm not an author of the code-coverage library. Therefore I can't give you the details.
However while testing for the issue the minimal, reproducible setup were two files:
A.php:
<?php
declare(strict_types=1);
namespace Neunerlei\Arrays;
class A
{
use ATrait;
}
ATrait.php
<?php
declare(strict_types=1);
namespace Neunerlei\Arrays;
trait ATrait
{
}
In that case A.php:8 is marked as "not executed"
I resolved the issue for me, by migrating to PHP 7.4 where everything works as expected.
Martin |
|
|
Sorry, that that "tomorrow" became 6 months later.
I have had a long look at this, and I think I have come to the conclusion that I do not want to address this right now.
Code coverage analyses which code can be executed when code coverage is active, and a new scope (script, method, or function) is seen for the first time. When code then runs, it modifies this information with whether code has been executed when specific lines have been hit. When code coverage was implemented, it was never meant to be stopped and started between every test, but rather, collect information for the whole execution as all the tests in one go. This means that it is now impossible to reset the internal collected information to the analysed stated (which line is executable etc). The only way would be to reanalyse everything. And that'd be so slow that nobody would ever want to do code coverage again.
The only way to solve this is to split the "analyse what code can do what" and "collect which lines/etc have been hit" into two separate internal data stores, and merge that information when returning it with xdebug_get_code_coverage(). That's going to be a major undertaking (read: months), and I don't think I will have the time for that, considering all the other issues I want to fix, and features to add.
Considering that you no longer have this problem with PHP 7.4, and that PHP 7.3 and older are no longer supported, I feel OK with closing this issue. |
