Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[DI] Bug in autowiring collisions detection#21658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
GuilhemN commentedFeb 18, 2017
Maybe we could split the AutowirePass in two parts: first, we would register all the missing services; in a second time, we would do the real autowiring. That would fix this issue but probably other edge cases would still be there. Sounds like a complicated issue. Another idea: store the types used previously and check that new services registered don't implement them. |
nicolas-grekas commentedFeb 19, 2017
Closed in favor of#21665 |
…(nicolas-grekas, GuilhemN)This PR was merged into the 2.8 branch.Discussion----------[DependencyInjection] Fix autowiring collisions detection| Q | A| ------------- | ---| Branch? | 2.8| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets | -| License | MIT| Doc PR |Fixes#21658 by implementing the second proposal of#21658 (comment):> Another idea: store the types used previously and check that new services registered don't implement them.Commits-------bb70472 [DependencyInjection] Fix autowiring collisions detection6f578ee [DI] Bug in autowiring collisions detection
…(nicolas-grekas, GuilhemN)This PR was merged into the 2.8 branch.Discussion----------[DependencyInjection] Fix autowiring collisions detection| Q | A| ------------- | ---| Branch? | 2.8| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets | -| License | MIT| Doc PR |Fixessymfony/symfony#21658 by implementing the second proposal ofsymfony/symfony#21658 (comment):> Another idea: store the types used previously and check that new services registered don't implement them.Commits-------bb70472dce [DependencyInjection] Fix autowiring collisions detection6f578ee514 [DI] Bug in autowiring collisions detection
…andidates (nicolas-grekas)This PR was merged into the 2.8 branch.Discussion----------[DI] Don't use auto-registered services to populate type-candidates| Q | A| ------------- | ---| Branch? | 2.8| Bug fix? | yes| New feature? | no| BC breaks? | no (every bug fix is a bc break, isn't it?)| Deprecations? | no| Tests pass? | yes| Fixed tickets |#22162, ~~#21658~~| License | MIT| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->Alternative to#22170 and ~~#21665~~.The core issue fixed here is that auto-registered services should *not* be used as type-candidates.The culprit is this line:`$this->populateAvailableType($argumentId, $argumentDefinition);`Doing so creates a series of wtf-issues (the linked ones), with no simple fixes (the linked PRs are just dealing with the simplest cases, but the real fix would require a reboot of autowiring for every newly discovered types.)The other changes accommodate for the removal of the population of the `types` property, and fix a few other issues found along the way:- variadic constructors- empty strings injection- tail args removal when they match the existing defaultsCommits-------992c677 [DI] Don't use auto-registered services to populate type-candidates
That's a failing test case, showing that autowiring collisions detection sometimes relies on ordering, which should not be the case.