Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[DependencyInjection] Fix autowiring collisions detection#21665

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

Merged
fabpot merged 2 commits intosymfony:2.8fromGuilhemN:AUTOWIRING
Feb 19, 2017

Conversation

@GuilhemN
Copy link
Contributor

@GuilhemNGuilhemN commentedFeb 18, 2017
edited
Loading

QA
Branch?2.8
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets-
LicenseMIT
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.

@nicolas-grekas
Copy link
Member

The benefit here is simplicity, the drawback is that this won't work with setter autowiring, where instead of throwing, we skip. Can you try something on master also see if you can make this approach fit there or if we need v1?

@GuilhemN
Copy link
ContributorAuthor

GuilhemN commentedFeb 18, 2017
edited
Loading

@nicolas-grekas you're talking about the fact that an exception could be throw when using a setter, right? Imo this is a very weird case and I don't think we should take position here, I think it's better to throw an exception and let the user manually fix the issue. For example, should a service created for a constructor win against a setter?

@nicolas-grekas
Copy link
Member

My bad: on conflicts, an exception is always thrown even for setters, so should be good.
But the check should be done outside of the autowiring loop - any ambiguous type must throw - setter or not.

GuilhemN reacted with thumbs up emoji

$classOrInterface =class_exists($type) ?'class' :'interface';
$matchingServices =implode(',',$this->types[$type]);

thrownewRuntimeException(sprintf('Unable to autowire argument of type "%s" for the service "%s". Multiple services exist for this %s (%s).',$type,$id,$classOrInterface,$matchingServices));
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Only the last service in which the type is used will be shown, would you prefer a list of all of them?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

the last is enough to me

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Ok, let's keep it as is :)

}

foreach ($this->usedTypesas$type =>$id) {
if (isset($this->usedTypes[$type]) &&isset($this->notGuessableTypes[$type])) {
Copy link
Member

@nicolas-grekasnicolas-grekasFeb 19, 2017
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

&& !isset($this->definedTypes[$type])?

Copy link
ContributorAuthor

@GuilhemNGuilhemNFeb 19, 2017
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

That was legit actually, that made me catch a bug (see#21670).

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

@fabpot
Copy link
Member

Thank you@GuilhemN.

@fabpotfabpot merged commitbb70472 intosymfony:2.8Feb 19, 2017
fabpot added a commit that referenced this pull requestFeb 19, 2017
…(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
@GuilhemNGuilhemN deleted the AUTOWIRING branchFebruary 19, 2017 16:11
@GuilhemN
Copy link
ContributorAuthor

Tell me if you need help to merge this in higher branches, it needs to be adapted (notGuessableTypes ->ambiguousServiceTypes, add getters autowiring support).

@fabpot
Copy link
Member

@GuilhemN Indeed, if you can submit a PR for higher branches, that would help. Thanks.

@GuilhemNGuilhemN mentioned this pull requestFeb 19, 2017
This was referencedMar 6, 2017
fabpot added a commit that referenced this pull requestApr 3, 2017
…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
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@GuilhemN@nicolas-grekas@fabpot@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp