I made the 2.7.2 release release available at the start of the month. This released addressed a few bugs:

• Issue #1488: Rewrite DBGp 'property_set' to always use eval

• Issue #1586: error_reporting()'s return value is incorrect during debugger's 'eval' command

• Issue #1615: Turn off Zend OPcache when remote debugger is turned on

• Issue #1656: remote_connect_back alters header if multiple values are present

• Issue #1662: __debugInfo should not be used for user-defined classes

The first issue has been lingering since when Xdebug introduced support for PHP 7. PHP 7 changes the way how variables are handled in the engine, which means that is a lot harder to obtain a zval structure that is modifiable. Xdebug uses that existing functionality in the step debugger to modify a variable's contents, but only if a variable type was explicitly set as well. Because it is no longer possible to retrieve this zval structure for modification, Xdebug switched from direct modification to calling the engine's internal eval_string function to set new values for variables.

Xdebug's wrapper around the engine's eval_string function is also used when running the DBGp eval command. IDEs use this for implementing watch statements. Because Xdebug shouldn't leak warning or error messages during the use of DBGp protocol commands, Xdebug's wrapper sets error_reporting to 0. However, that means if you would run error_reporting() through the DBGp protocol with the eval command, it would always return 0. The second bug (#1586) fixed this, so that running error_reporting() with eval now returns the correct value.

The third issue in the list addresses a problem with Zend OPcache's optimiser turned on. It is possible that with optimisations turned on, variables no longer exist, or useless statements are removed to make your code run faster. However, this is highly annoying when you are debugging, because you can no longer reliably inspect what is going on. By turning of the code optimisation when Xdebug's step debugger is active, normality is restored.

The last two items in the 2.7.2 release are minor bug fixes.

The fine folks at Jetbrains have looked at my implementation of issue #1388: Support 'resolved' flag for breakpoints. They found that although the implemented functionality works, it would not yet handle the resolving of breakpoints which are set in a scope that is currently being executed (i.e., when the function, method, or closure is currently active). I have briefly looked at solving this problem, but have not yet found a good solution. In addition, I am intending to change the line searching algorithm to scan at most 5 lines in each directions instead of 10. This should prevent unnecessary jumping around, and unintended breaks.

The rest of the time I spent at making Xdebug ready for PHP 7.4. This new version has some internal changes that require Xdebug to be updated. Although Xdebug now works with PHP 7.4 through the PHP-7.4-support branch, the tests don't yet all pass. One of these changes is that while PHP previously would have a line of executable code on every method and class definition, this opcode is no longer generated. This means that all of my code coverage tests are now broken. As part of making the tests pass again, I have started at making the requirements checks in each test case easier to set-up and maintain. This is taking a significant amount of time. I hope to have this branch merged when PHP 7.4alpha1 comes out. I also intend to release an alpha version of Xdebug 2.8 shortly after that, which should also include the update to the Resolved Breakpoints functionality.

I have been continuing with the PHP Internals News podcast. In this weekly podcast, I discuss in 15-30 minutes, proposed new features to the PHP language with fellow PHP internals developers. It is available on Spotify and iTunes, and through an RSS Feed. Let me know if you are a listener!