Currently, Xdebug's code coverage reporting only indicates whether a line has been executed; it doesn't capture how often it has been executed between xdebug_start_code_coverage() and xdebug_get_code_coverage()/xdebug_stop_code_coverage().

I would like to propose the restoration and enhancement of Xdebug's line-level execution counting capability. This would allow the tracking of how many times each line of code is executed during code coverage analysis, rather than simply marking lines as either executed (1), not executed (0), or not reachable (-1) (when dead code analysis is enabled).

Xdebug previously tracked how often a line was executed. This changed in 2004 (see https://github.com/xdebug/xdebug/commit/8d6392a51#diff-463e9f0296d2e3108dd01d49d3a11016f7b5f85048f4a56dc83c9341490b9e10L148), replacing the count with a simple binary indicator (1 for executed, 0 for not executed). During a discussion, Derick suspected that this change had been made back then to address the situation in which the number of times a line was executed was incremented for each statement on that line that was executed. Also in this discussion, Derick suggested the following improvements over the original implementation:

1) Implement the execution counting as a flag, allowing developers to opt into the more detailed reporting when needed rather than making it the default behavior.

2) Only count an execution if the line number differs from that of the previous execution. This would count how many times execution enters a particular line. This approach addresses the aforementioned issue, counting the line once per entry to it, rather than once per executed statement on it.

Currently, PHPUnit only reports the number of tests that executed a line. Once the change requested here is implemented, I will adapt PHPUnit's HTML code coverage report to show both the number of tests that executed a line of code ("distinct coverage") and the total number of times that line of code was executed during the execution of the test suite ("execution count"). Future work might include calculating and reporting additional software metrics derived from these two values.