I see two issues here:

• the first, minor, is that the vendor dir is not always called "vendors"
• the second is more serious: any code in vendors is always called by some code in userland. Code don't get called magically - but because userland asked for it - thus there is not such thing as "vendor deprecations" vs others. Or do you have a way to decide that works reliably?

1. Yes that's an issue (see my todo list), maybe I can work around that with another env var?
2. Not an issue IMO, I'm only looking at the first file of the stack trace, which is the one wheretrigger_error is written. Quoting themanual : "The third parameter is optional, errfile, which contains the filename that the error was raised in, as a string. " So to sum up, a deprecation is a "vendor deprecations" iff thetrigger_error that raises it is written in a file that lives invendor

Third issue, even more minor, some people might have avendor directory inside theirsrc (why not). Might be solvable with__DIR__ though.

I'm only looking at the first file of the stack trace

That means you target deprecations triggered by code in src/. Ok.

For vendors, see my PR about ComposerResource.

I'm only looking at the first file of the stack trace

Actually that was wrong and has nothing to do with the stack trace, I'm looking at the$errfile argument of the error handler function. So if I have a file insrc, that calls a function from thevendor dir, that has atrigger_error in it,$errfile will bevendor/callee.php, and notsrc/caller.php, right?

For vendors, see my PR about ComposerResource.

link for the lazy

link for the laziest 😄

Maybe I should explain a bit more the goal of this PR, I feel I'm being unclear.

This is going to used way more in libs than in project, that seldom use deprecation notices themselves.@nicolas-grekas I think that's why you talk about userland vs vendors.

Let there be lib X, that has n dependencies. Anytime any of the n dependencies introduces a new deprecation, I have to fix it, andno PR can be merged during that time, unless I useSYMFONY_DEPRECATIONS_HELPER=weak.

And that's what I do most of the time, because I don't want to shift the burden of fixing these to anyone who wants to contribute anything unrelated to the vendor lib, and has the bad luck of doing so at the wrong time.

Now let's suppose a contributor submits a new PR, and let's suppose that that PR introduces a deprecation notice inthe codebase of the lib , and by that I don't mean a deprecated call to another lib, I mean a call totrigger_error directly. Then they must be careful to mark all corresponding tests with@group legacy, and fix all calls throughout the codebase of the lib so that they use the new way of doing things.

In my experience, many people forget to do that, and deprecations are introduced, that could easily be avoided. Seethis PR where I end up doing the work that should have been done by the contributor from the start.

Doc PR would be really nice before merging since the use case should be explained there :)

@greg0ire the issue is that your logic looks wrong. Vendor deprecations must not be distinguished based on the location of the deprecation, but based on the caller location.
You will almost never call your own deprecated code, as you are also the one deprecating it. However, you are very likely to be calling a deprecated method of one of your dependency. In this case,trigger_error is inside the vendor folder, but the place needing to be fixed is inside your own code.
And using the backtrace to identify whether it is called from your own code or no is fragile, because your code may not be the direct caller. We have cases in Symfony where we have more classes between your own code and the code triggering the deprecation for instance, while the fix is still needed in your own code, for instance when asking to migrate from a type name to a class name to reference form types in Symfony 2.8

You will almost never call your own deprecated code, as you are also the one deprecating it

That's precisely the case I'm trying to help fix however.There are contributors that contribute new deprecations, and forget to fix these calls. Then it get merged, but could have easily be prevented. Also, there are tests that are marked with@group Legacy (note the capital), which does not work either. That could also have been prevented easily. Or they just outright forget to mark tests with@group legacy That's what I want to catch here.

And using the backtrace to identify whether it is called from your own code or no is fragile

I'm not doing that (I think). I'm not indentify the caller location, I'm identifying the callee location. When developing a lib, the lib is always calling others or itself, but no other lib is calling my lib. So in that case, I think it's safe to want to know "is there any call to a deprecated methodof my lib in the codebaseof my lib?"

Doc PR would be really nice before merging since the use case should be explained there :)

Didn't notice your comment. Will do!

Here is the docs PR

Thanks, just posted a few short notes

I changed the code so that other modes output is no longer split into vendors / non-vendors.

I fixed the colorization issue, deprecation notices are always in yellow now.

fabbot reports errors that should be fixed.

@fab{b,p}ot : fixed

I rebased again, can anyone review and remove the "Needs work" label? This is supposed to be finished.

Changed the poor man's error handler fromvar_dump toprint_r after discussing with@Nek-

This is supposed to be ready on my end, please review again.

Thank you@greg0ire.

Made a separate PR for the poor man's error handling :#21795