Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bug #22282 [DI] Prevent AutowirePass from triggering irrelevant depre…
…cations (chalasr) This PR was merged into the 2.8 branch. Discussion ---------- [DI] Prevent AutowirePass from triggering irrelevant deprecations | Q | A | ------------- | --- | Branch? | 2.8 | Bug fix? | no (just a failing test case atm) | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | no | Fixed tickets | n/a | License | MIT | Doc PR | n/a For populating available types the AutowirePass iterates over `$container->getDefinitions()` trying to instantiate a reflection class for each definition. Problem is that if one of these classes is deprecated, a notice is triggered due to the reflection, even if the service is actually never used. ~~Right now this only reproduces the issue with a failing test case~~, this bug (if we agree it's a bug) breaks the test suite of a bundle I maintain (see https://travis-ci.org/lexik/LexikJWTAuthenticationBundle/jobs/218275650#L262) Solutions I can think about for now: - ~~Skip deprecated definitions from type registering, meaning that if a service is deprecated a day, all autowired services that rely on it will suddenly be broken, also the bug would remain if the definition is not deprecated but relies on a deprecated class, not good I think~~ - Register an error handler ignoring deprecations during the type registering process (`AutowirePass#populateAvailableType()`), ~~works but makes my test suite say `THE ERROR HANDLER HAS CHANGED`. I'll push my try as a 2nd commit.~~ Thoughts? Commits ------- 77927f4 [DI] Prevent AutowirePass from triggering irrelevant deprecations
- Loading branch information