This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Remove skipping magic for autowired methods
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (master only)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Wildcard based autowiring made it required to auto-skip methods that were not wireable.
Now that things need to be explicit (ie via the `@required` annotation, or via configuration), this "automagic" behavior is not required anymore.
Since it can lead to wtf moments ("*I* did *put that `@required` annotation, why is it ignored by autowiring?*"), I think we should remove it.
This also fixes another issue where configured method calls had their optional arguments wired, while we want only the constructor's to behave as such.
Commits
-------
a6bfe1c [DI] Remove skipping magic for autowired methods
This PR was squashed before being merged into the 3.3-dev branch (closes#21763).
Discussion
----------
[DI] Replace wildcard-based methods autowiring by `@required` annotation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (affects things that are only on master)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
While playing a bit with new features in master around DI configuration, several people around me got bitten by wildcard-based autowiring. The typical example is adding `autowire: [set*]` in `_defaults`: use that on `resource: ../src/Command/` PSR4-based loading and boom, `setApplication` and `setHelperSet` will now be wrongly called. You could tell me "of course, don't to that" - but being bitten so early on a master-only feature makes me really unconfident that this will be easy enough for people after the release.
If wildcard-based autowiring is removed, then I don't see anymore the need for allowing arrays as in `autowire: [setFoo,getBar]`. Moreover, this array syntax has a core DX issue: it's a dead end as far as the learning curve is concerned. You learn it, then when becoming a more advanced dev, someone teaches you that you'd better use another syntax: explicit wiring.
And in fact, we don't need it at all, because something else already exists: just declare a method call, but don't define its arguments. If `autowire: true` is set, then the AutowiringPass already fills in the holes. There is only one tweak required to make this work: don't autowire optional arguments for method calls - or that'd be a BC break. To my PoV that's even better: this makes autowiring fit a "do the minimum to make it work" strategy. A really good one to me.
But there is still an issue: wildcard-based autowiring fits a need. Namely, it allows one to define a convention (eg. `'set*'`), and have all such methods that follow the convention be autowired. To me, this looks like doing it reverse (the DI config should adapt to the code, not reverse). So, to fill this need, let the declaration be in the source: just use an annotation!
This PR adds support for the `@required` annotation, borrowed from the Spring framework:
https://www.tutorialspoint.com/spring/spring_required_annotation.htm
Using the annotation is totally optional of course. If you do, *and if autowiring is on*, then it'll be autowired. If you don't, nothing changes: do manual wiring.
Even when not using autowiring, the annotation is still a nice hint for the consumer of your classes: it tells the reader that this method needs to be called for correct instantiation - thus lowering one drawback of setter injection (discoverability).
The implementation of the annotation parsing is done using a few regexp (no dep on any complex parser) - and works with inheritance, by leveraging the `@inheritdoc` tag (the default behavior being to *not* inherit anything from parent methods).
All in all, looking at the diff stats, it makes everything simpler. Good sign, isn't it?
Commits
-------
f286fcc25f [DI] Replace wildcard-based methods autowiring by `@required` annotation
9081699980 Revert "minor #21315 [DI][FrameworkBundle] Show autowired methods in descriptors (ogizanagi)"
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Simplify AutowirePass and other master-only cleanups
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
A few minor cleanups and fixes, and an overall simplification of AutowirePass.
Commits
-------
34e5cc7698 [DI] Simplify AutowirePass and other master-only cleanups
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Always consider abstract getters as autowiring candidates
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes (a missing part of getter autowiring really)
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
When a definition is set to be autowired with no method explicitly configured, we already wire the constructor.
We should also autowire abstract getters - with the same reasoning that makes us autowire the constructor: without concrete getters, the class is unusable. This just makes it usable again.
Commits
-------
8f246bde1d [DI] Always consider abstract getters as autowiring candidates
* 3.2:
[DependencyInjection] Fix using autowiring types when there are more than 2 services
[DependencyInjection] Fix autowiring collisions detection
[DI] Bug in autowiring collisions detection
* 2.8:
[DependencyInjection] Fix using autowiring types when there are more than 2 services
[DependencyInjection] Fix autowiring collisions detection
[DI] Bug in autowiring collisions detection
This PR was merged into the 2.8 branch.
Discussion
----------
[DependencyInjection] Fix autowiring types when there are more than 2 services colliding
| 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 |
There is a bug in the `AutowirePass`, when using more than 2 services colliding and you want to use the autowiring types: it may not work depending on their order because `notGuessableTypes` is not reset.
Commits
-------
5981278537 [DependencyInjection] Fix using autowiring types when there are more than 2 services
* 3.2:
Permit empty suffix on Windows
fixed CS
[FrameworkBundle] Remove unused import
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
* 2.8:
Permit empty suffix on Windows
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
* 2.7:
Permit empty suffix on Windows
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
This PR was merged into the 2.7 branch.
Discussion
----------
[DependencyInjection] check for circular refs caused by method calls
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #19362
| License | MIT
| Doc PR |
Before we check for circular references, dependencies coming from method calls are not part of the dependency graph. That why the pass is not able to detect circular references like the one described in #19362 during compilation of the container.
If we add another check after all the optimisation passes have been processed, we should be able to detect these circular references too.
Commits
-------
fe4f7eccf7 check for circular refs caused by method calls
This PR was merged into the 2.7 branch.
Discussion
----------
[DI] Auto register extension configuration classes as a resource
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
Auto-register an extension configuration class as a resource from a compiler pass; not implicitly by the base extension class.
Causing some extensions to register its configuration, whereas others dont (e.g. framework bundle).
Fixes consistent cache invalidation whenever a configuration definition changes.
Commits
-------
142416b7d4 [DI] Auto register extension configuration classes as a resource
* 3.2: (27 commits)
Improve tracking of environment variables in the case of private services
[DI] Align AutowirePass with 2.8
property constraints can be added in child classes
added test for staticClassLoader in LazyLoadingMetadatafactory
fixed PHPUnit setUp and tearDown method visibility
spelling fixes
Readd Symfony version status in the toolbar
[Security] LdapUserProvider should not throw an exception if the UID key does not exist in an LDAP entry
make sure that null can be the invalid value
[VarDumper] Improve dump of AMQP* Object
Fix annotations cache folder path
[FrameworkBundle] Wire ArrayCache for annotation reader at bootstrap
Ignore missing 'debug.file_link_formatter' service in Debug bundle
[VarDumper] Fixed dumping of terminated generator
bumped Symfony version to 3.2.4
updated VERSION for 3.2.3
updated CHANGELOG for 3.2.3
bumped Symfony version to 2.8.18
updated VERSION for 2.8.17
updated CHANGELOG for 2.8.17
...
* 2.8:
property constraints can be added in child classes
added test for staticClassLoader in LazyLoadingMetadatafactory
spelling fixes
Readd Symfony version status in the toolbar
make sure that null can be the invalid value
[VarDumper] Improve dump of AMQP* Object
[VarDumper] Fixed dumping of terminated generator
bumped Symfony version to 2.8.18
updated VERSION for 2.8.17
updated CHANGELOG for 2.8.17
bumped Symfony version to 2.7.25
updated VERSION for 2.7.24
update CONTRIBUTORS for 2.7.24
updated CHANGELOG for 2.7.24
[FrameworkBundle] Simplify createPackageDefinition
fix directory resource considers same timestamp not fresh
return false early from directory resource
* 2.7:
property constraints can be added in child classes
added test for staticClassLoader in LazyLoadingMetadatafactory
spelling fixes
make sure that null can be the invalid value
bumped Symfony version to 2.7.25
updated VERSION for 2.7.24
update CONTRIBUTORS for 2.7.24
updated CHANGELOG for 2.7.24
[FrameworkBundle] Simplify createPackageDefinition
fix directory resource considers same timestamp not fresh
return false early from directory resource
This PR was merged into the 3.2 branch.
Discussion
----------
[DI] Align AutowirePass with 2.8
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Follow up a less than ideal [merge conflict resolution](https://github.com/symfony/symfony/pull/18691#issuecomment-218803903), found while reviewing AutowirePass in 2.8 and 3.2 and wondering about the delta. Should reduce future merge conflicts and help history tracking.
Commits
-------
dd5236a [DI] Align AutowirePass with 2.8
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Config][DI] Add ComposerResource to track the runtime engine + deps
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
So that the container is invalidated whenever a new PHP runtime is used, a PHP-extension is added, or vendors are changed.
Commits
-------
a960c761d1 [Config][DI] Add ComposerResource to track runtime + vendors
