Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has acontribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (seehttps://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://symfony.com/releases)
• Features and deprecations must be submitted against the 5.x branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

I think the current code already handles the situation. It's just not released yet.
Please have a look at#40679

It attempts to handle it yes. In an ideal world, we could avoid the call and avoid using the at-suppression/shut operator (a good php practice is if you can avoid @-suppression, you should).

In the current unreleased codebase, the function is still called, and if a custom error handler is currently registered, it too will be triggered (I am seeing this behavior):

https://www.php.net/manual/en/language.operators.errorcontrol.php

If a custom error handler function is set with set_error_handler(), it will still be called even though the diagnostic has been suppressed ...

As explained in xdebug's doc, the php.ini setting can be overriden by an env var. This means this check won't work all the time. You're right about the silencing operator. Maybe we could set a temporary "null" error handler instead of using it. Would you mind giving it a try in this PR?

You make a great point, ... I am inclined to just close this PR as I don't see any clean way of detecting the mode, and introducing another error handler to the stack doesn't feel like the right path.

The @-supression is probably a good enough stopgap until proper mode detection is built-in to xdebug:

xdebug/xdebug#733
https://bugs.xdebug.org/view.php?id=1898

Hopefully we can get this current fix with the @-suppression released soon? 😁

xdebug/xdebug#737 us the new PR

This looks great! ❤️ Thank you very much, Derick!