Skip to content

[DI] Don't use auto-registered services to populate type-candidates #22254

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 3, 2017

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Apr 3, 2017

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#...

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 defaults

if (isset($arguments[$index])) {
continue;
}

// no default value? Then fail
if (!$parameter->isOptional()) {
Copy link
Member

Choose a reason for hiding this comment

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

shouldn't this check isDefaultValueAvailable and allowsNull instead ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I added a check for isDefaultValueAvailable - but none for allowsNull because unless I'm wrong, we don't need it.

Copy link
Member Author

Choose a reason for hiding this comment

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

and I just reverted this change, because there is nothing wrong here: at this stage, an optional arg must have a default value, (but an arg with a default value is not necessarily optional)
so all good to me as is

Copy link
Member Author

@nicolas-grekas nicolas-grekas Apr 3, 2017

Choose a reason for hiding this comment

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

the current behavior is a tested one, so I'll adjust on master to fit named args, nothing to do here to me

@theofidry
Copy link
Contributor

  1. Correct me if I'm wrong, but [DI] Successful construction of DIC depends on order of service definitions when depending on an interface which implementation is auto-registered #22162 has nothing to do with discovered services does it?

auto-registered services should not be used as type-candidates

  1. How does that translate concretely in the end for the users? I'm not sure to understand the real consequences of that :)

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Apr 3, 2017

@theofidry it is directly related: #22162 uses MyRepository as an auto-registered type-hint, which depending on the order of declarations might or might not be used as the implementation for RepositoryInterface, found in another constructor.

The concrete consequence of this PR is that instead of failing to autowire in some order-related situations, it will make it to always fail (#22170 tries to make it always work, but I'd prefer to get rid of the existing 💩 instead :).)

@stof
Copy link
Member

stof commented Apr 3, 2017

@nicolas-grekas I prefer your approach rather than adding more complex magic requiring a 2-step processing of definitions.

@@ -252,13 +262,11 @@ private function createAutowiredDefinition(\ReflectionClass $typeHint, $id)
throw new RuntimeException(sprintf('Unable to autowire argument of type "%s" for the service "%s". No services were found matching this %s and it cannot be auto-registered.', $typeHint->name, $id, $classOrInterface));
}

$argumentId = sprintf('autowired.%s', $typeHint->name);
$this->autowired[$typeHint->name] = $argumentId = sprintf('autowired.%s', $typeHint->name);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't we populate just one type instead? e.g. $this->types[$typeHint->name] = $argumentId

Copy link
Member Author

@nicolas-grekas nicolas-grekas Apr 3, 2017

Choose a reason for hiding this comment

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

I looked into this, and didn't find much benefit in doing so, counting LOC - also conceptually that's no exactly the same (as hinted by https://github.com/symfony/symfony/pull/22254/files#diff-62df969ae028c559d33ffd256de1ac49R135)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, as there is the false support I don't see much benefit too.
Fine for me as is then 👍


$arguments = $definition->getArguments();
foreach ($constructor->getParameters() as $index => $parameter) {
foreach ($parameters as $index => $parameter) {
if (array_key_exists($index, $arguments) && '' !== $arguments[$index]) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we actually need this, it makes one more thing to learn while we could achieve the same using manual indexes or named arguments.

Copy link
Member

Choose a reason for hiding this comment

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

named arguments are a 3.3 feature. This PR targets 2.8. So we need to keep this feature in 2.8

Copy link
Member Author

Choose a reason for hiding this comment

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

this is committed behavior, we can't change now

Copy link
Contributor

Choose a reason for hiding this comment

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

Indeed, that's a comment for 3.3, I'll open a different PR to discuss this.

Copy link
Member

Choose a reason for hiding this comment

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

This behavior is still useful in XML (but not in YAML IMO).

Copy link
Member

@stof stof left a comment

Choose a reason for hiding this comment

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

👍

Copy link
Member

@dunglas dunglas left a comment

Choose a reason for hiding this comment

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

👍, it should have been the default since the beginning. The only thing annoying to me is that this change may break a few apps. Maybe should this "new" behavior mentioned in the CHANGELOG?

@nicolas-grekas
Copy link
Member Author

Not sure where this should be added. It will be in the changelog as usual of course.

@fabpot
Copy link
Member

fabpot commented Apr 3, 2017

Thank you @nicolas-grekas.

@fabpot fabpot merged commit 992c677 into symfony:2.8 Apr 3, 2017
fabpot added a commit that referenced this pull request Apr 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 defaults

Commits
-------

992c677 [DI] Don't use auto-registered services to populate type-candidates
@nicolas-grekas nicolas-grekas deleted the di-autow28 branch April 4, 2017 08:37
This was referenced Apr 5, 2017
@enumag
Copy link
Contributor

enumag commented Apr 6, 2017

BC breaks? no (every bug fix is a bc break, isn't it?)

Not entirely sure if it was caused by this change or some other commit but the fact is that in Symfony 3.2.7 autowiring doesn't work for me at all (3.2.6 is fine). In the compiled container many services are created with no arguments at all instead of their autowired dependencies.

Type error: Too few arguments to function AppBundle\Util\Formatter::__construct(), 0 passed
in .../app/cache/dev/appDevDebugProjectContainer.php on line 2516 and exactly 3 expected

@nicolas-grekas
Copy link
Member Author

Last comment fixed in #22311

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants