Roave
Report addition of `trigger_error()` to a function's body as a BC break
Functions that are otherwise working fine cannot have trigger_error() expressions added to them, as that:
- breaks downstream consumers (output, loggers, test suites)
- introduces an unwanted side-effected, which could potentially cause major issues in a production environment
Therefore, we will add a new checker that ensures that trigger_error() additions are considered BC breaks.
That is pretty much the reason why this issue exists: userland deprecations in previously working code, breaking downstream consumers.
It's a dangerous and irresponsible approach perpetrated by symfony/* packages.
I mean, if you don't configure your app to ignore deprecations you can't really blame anyone.
It's not just apps: it's a whole chain of libraries, tools and thousands of hours of work, just to stay in sync with side-effects introduced very deep in your stack frames.
For instance, in this specific library, a deprecation warning will break e2e tests, because STDERR is broken by those, and output buffering will catch them.
In other systems, an unrelated error listener may be tripped: potentially not even configured at application level, but deep in a library.
In other systems, performance may be crippled.
On systems that log all errors, disk space may become an issue.
In practice: don't add RUNTIME effects where none were present, because that is a clear BC break. We have the tools, and there is no need to make these problems a runtime side-effect.