Dealing with deprecations from Symfony DebugClassLoader

[mpdude]

DebugClassLoader from symfony/error-handler has the interesting feature that it can be set up as an autoloader and do on-the-fly source code analysis. It will trigger deprecation notices e. g. when a class implements an interface that announces future return types, and the implementing class needs to add the return type on their side first. It can also help with transitioning classes to become final or with adding new parameters to methods.

In case it has something to report, it will @trigger_error(..., E_USER_DEPRECATED) deprecation notices from one or two stack frames deep within the autoload code.

Goal: I would like to know when my (first party code) classes have such issues; at the same time, I would like to ignore these issues in third party code, potentially even ignoring indirect deprecations altogether.

The challenge with these deprecations is that

1. You might need to filter more than one stack frame to find the code actually triggering loading of the class. I am not sure if that is currently possible with PHPUnit. I had the impression that <deprecationTrigger> filters only one element. not true
2. Most of the time, the code triggering the autoload is third party code, e. g. the Symfony DIC container booting the application
3. The code triggering the deprecation is never within my own (first party) code, it is always the autoloader – also when loading third party classes. I am not sure if the class in question is already loaded at the time the error is triggered, but anyway, it is not (as a file) in the call stack at that time.

Potential solutions

I currently have two ideas for discussion.

First, what if I could configure the DebugClassLoader either as a class or on a method level similar to <deprecationTrigger>, but with the effect that errors triggered from there will always be reported?

With that, I could at least keep indirect deprecation notices in general turned off. Only deprecation notices from DebugClassLoader would be reported, albeit they contain also notices for third-party classes being loaded.

Second, maybe it would be possible to detect the autoloader situation e. g. by recognizig the error-triggering function or method as a declared autoloader function, and then work backwards through the stack trace to find the class that needs to be loaded? (Can we see the autoloader argument in the stack trace at all?) Then, classify this class as either being first or third party code.