This is really awesome! 👍

👍 for separating them, though I'd like the deprecation count to actually be 1 in this case.

I don't know if this separation means anything. I mean: all the code you end up calling is your responsibility. At the technical level, drawing this line might be hard. But of course, this is just an apriori and I'd be happy to be wrong :)

@nicolas-grekas it makes it possible for me to check which deprecations I can easily fix, which is quite nice as I don't have to immediately check the vendors yet.

@javiereguiluz would it be possible to determine the vendor reporting the deprecation? We should have it available in the context, but it would be really nice to see who reported it without having to open that.

it makes it possible for me to check which deprecations I can easily fix, which is quite nice as I don't have to immediately check the vendors yet.

I get that. What I mean is that this may have no real basis at the code level, so that implementing this might just be impossible, or be very biased towards some empirical way of separating these at the technical level.

Ah fair enough, I see your point. I guess you can only scan the context for classes/paths and determine the origin based on that.

You can get the application namespaces from composer.json, than its easy to make the separating

the vendor reporting the deprecation does not tell you which code triggered it. for instance, in the screenshot above, the fact that SFEB reports the usage of a deprecated config setting highlights an issue in your code, not in SFEB (and so it was wrongly qualified in the screenshot).

Relates to #24867 (docs PR: symfony/symfony-docs#8686)

Closing because some Core Team members with deep knowledge about this said that it's probably impossible to implement ... and I think they are right!

the vendor reporting the deprecation does not tell you which code triggered it.

Yeah but it is doable by examining the stack trace, and determine whether it switches from SFEB to another vendor, or to your code.

be very biased towards some empirical way of separating these at the technical level.

The assumption one has to make in order to implement this is that all involved vendors use psr-0 or psr-4 autoloading. From there you can have a Composer package name by examining the filenames in the stack trace.

This was possible for me to implement in the deprecation error handler #24867, not sure how similar things are with the profiler, maybe there is something I'm missing.

Just found this issue while I was basically opening the same one.

I don't get why it's impossible. I see 2 cases :

• The deprecations triggered directly in the code by a trigger_error() call. I guess we can check the backtrace to filter everything that was not caused directly by "my source code directories". By directly I mean the file location of the last function before the one that called trigger_error().

• The deprecations triggered by the DebugClassLoader. I guess we can filter every files that are not in "my source code directories" since we have their paths.

"my source code directories" cannot be defined magically ofc.

Wouldn't that be enough to filter out most of the cases ?

The deprecations triggered directly in the code by a trigger_error() call. I guess we can check the backtrace to filter everything that was not caused directly by "my source code directories". By directly I mean the file location of the last function before the one that called trigger_error().

That assumption is wrong, deprecation warning can come from deprecated features being used in the project even if the caller isn't.

The 2 cases that comes to my mind immediately are:

• Deprecated config options: the whole stack trace will be composed of framework code but it's still you that used the option.
• Deprecated form options: the caller of the option resolver that trigger the deprecation warning is the form factory.

Yes those to could be filtered that the code handling sorting the deprecation. But they could be other cases that I didn't think and even if I did, other cases could be added by bundles.

Since this feature can't be added without the risk of producing false negatives (deprecations that are reported as cased by others while they are your responsibility) I think it souldn't be added as it would cause more harm than good.

Thank you for those two great examples and explanations!

What about the ones from the DebugClassLoader? That would still be an improvement.

I'm not 100% sure of how the DebugClassLoader works but based of what I know:

I think they are 2 cases that cans be triggered in the DebugClassLoader:

• when you directly try to load a deprecated class
• when you load a class that extends a deprecated class

The first one suffer the same problem that normal deprecation, for example you could pass a $class parameter to a bundle that then do a new $class() triggering the loading the class.

For the second case I can't find a case when the deprecation could be wrongly reported.

But even if we could classify some of the deprecation I think having 3 categories (your code, vendor code, we don't know) would be more confusing than do good, especially since most deprecations would be in the "we don't know" category.