The error is silenced L432, see

It should thus not be reported. Why is it?

@nicolas-grekas You're right - but there is another include, L458 (see in "Additional context"). To that line it could be "unsilenced", as the trick you mentioned applied only for the 1st include.

@nicolas-grekas I found the reason: I have error_reporting(E_ALL); in the begin of my index.php - so restoring the value makes it to avoid suppressing this warning.
I guess it's still a bug and should be fixed by suppressing warning only around includes.

@nicolas-grekas Still answering your question)) According to docs, error_reporting is ignored in case if there is set_error_handler: https://www.php.net/manual/en/function.set-error-handler.php . It's my case: I have Sentry bundle installed, which obviously uses set_error_handler.
So the problem is that our way of silencing this warning is not silencing in case if you have error-reporting tools enabled (or enabled set_error_handler for another reason).
UPD I am going to debug how Sentry uses set_error_handler, I think it should respect changes of error_reporting. Regarding this open issue: I still think the PR is correct and should be merged - though it doesn't fix this particular issue but makes how we work with error_reporting more precise and accurate.

Closing as this has been identified as an issue on Sentry's side.
Note that I would advise not using Sentry's ErrorHandler in any Symfony app. Sentry should be wired as a monolog handler instead.

Note that I would advise not using Sentry's ErrorHandler in any Symfony app. Sentry should be wired as a monolog handler instead.

Could you elaborate on the reasons behind this, @nicolas-grekas? Since now I've preferred wiring Sentry in the bundle through the error handler since it's natively present from the base SDK, and the handler is designed taking inspiration from Symfony's.

The Monolog approach seemed fragile in the past, since I would have to rely on a secondary bundle (MonologBundle) to work; also, I'm not sure I would be able to collect some collateral info; not sure about this last point, I need to reevaluate now.

@Jean85 sure, let me try:

The error handler is a global piece of non-trivial code. I would expect all Symfony apps to behave exactly the same no matter whether there is a bug catcher around (Sentry, Bugsnag, etc). When there is a bug catcher, I would expect it to not change any global state - that's too tricky, especially when there is already a stack in place. Since Symfony already has this stack for handling errors, I would expect bug catchers to standardize on reusing it when used within a Symfony app. If you need one example of how this can go wrong, this very issue is the example. By definition, the Symfony stack is more proven (since it runs on apps that don't have Sentry). It can be trusted more. The conclusion is that: don't hook here Sentry.

Then:

The Monolog approach seemed fragile in the past, since I would have to rely on a secondary bundle (MonologBundle) to work;

If you want the bundle to be useful without Monolog bundle, I would recommend you to provide Sentry as a PSR-3 logger then. But when Monolog is installed, it should be leveraged, as it allows more powerful setups (e.g with the finger-crossed handler, etc.) But I wouldn't be shocked if monolog-bundle would be a dependency of sentry-bundle. Monolog is also more widely used than sentry-bundle - requiring it would satisfy the package principles.

I would be able to collect some collateral info; not sure about this last point, I need to reevaluate now.

I don't think you'd miss any info, but please report back if you find any of course.

Luckily PSR-3 handler is already present in the base SDK, so that option is already covered: if a user wants that, just skip the bundle. The bundle should just be a fast way to install Sentry with a nice out-of-the-box experience in a Symfony app.

I could try to change the hook, only downside that I see is that requiring explicitly the Monolog bundle is a no-go, because I would "silently" install it for the user. So I thought of a different approach: what do you think about hooking the PSR-3 handler directly to the Symfony error handler? I see that it has already some logger support there...

Otherwise, I could detect the presence of the bundle and act accordingly, but I would have to fall back to the current approach if Monolog is absent..

Otherwise, I could detect the presence of the bundle and act accordingly, but I would have to fall back to the current approach if Monolog is absent..

That should be the way to go then I think.

Loosely related: I would recommend sentry-bundle to use the symfony http-client by default also :)
I'd better have monolog-bundle as a dep than guzzle :)

Luckily PSR-3 handler is already present in the base SDK

@Jean85 No PSR-3 handler is provided from getsentry/sentry at the moment 😉

Otherwise, I could detect the presence of the bundle and act accordingly, but I would have to fall back to the current approach if Monolog is absent..

If we decorate the logger service so that it logs to Sentry too it will work with and without Monolog, but it could introduce a problem if someone then uses the same logger inside Sentry itself. We should prevent this somehow or add some notes to the documentation

@Jean85 No PSR-3 handler is provided from getsentry/sentry at the moment wink

We do have this: https://github.com/getsentry/sentry-php/blob/master/src/Monolog/Handler.php

If we decorate the logger service so that it logs to Sentry too it will work with and without Monolog, but it could introduce a problem if someone then uses the same logger inside Sentry itself. We should prevent this somehow or add some notes to the documentation

That's too generic and risky IMHO. I would stick to the previous suggested approach.

Loosely related: I would recommend sentry-bundle to use the symfony http-client by default also :)
I'd better have monolog-bundle as a dep than guzzle :)

The bundle doesn't have a direct dep, and the base library relies on PSR-18. Guzzle is just the out-of-the-box suggestion, you can change it anytime. Also, to use the Symfony client I would have to drop support for Symfony < 4.3, so maybe I could consider that in the future.

to use the Symfony client I would have to drop support for Symfony < 4.3

actually, since you already have php 7.1 as a minimum dependency, and since the http-client component is standalone, this can be used even if the rest of the stack is using mostly previous versions of Symfony components.