This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
`Reference` found in `ArgumentInterface::getValue()` are currently not inlined.
While trying to do so (hint: I failed), I noticed that the current code is broken for `IteratorArgument` which can contain anonymous `Definition` for now, which are then not inlined correctly.
This PR restricts `IteratorArgument` to arrays of `Reference`, and improves a few related things found while doing it.
(fabbot failure is false positive)
Commits
-------
4d3dce1c0f [DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Add "by-id" autowiring: a side-effect free variant of it based on the class<>id convention
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR adds a new autowiring mode, based only on the class <> id convention.
This way of autowiring is free from any conflicting behavior, which is what I was looking for to begin with.
The expected DX is a bit more involving than the current way we do autowiring. But it's worth it to me, because it's plain predictable - a lot less "magic" imho.
So in this mode, for each `App\Foo` type hint, a reference to an "App\Foo" service will be created. If no such service exists, an exception will be thrown. To me, this opens a nice DX: when type hinting interfaces (which is the best practice), this will tell you when you need to create the explicit interface <> id mapping that is missing - thus encourage things to be made explicit, but only when required, and gradually, in a way that will favor discoverability by devs.
Of course, this is opt-in, and BC. You'd need to do eg in yaml: `autowire: by_id`.
For consistency, the current mode (`autowire: true`) can be configured using `autowire: by_type`.
Commits
-------
c298f2a90c [DI] Add "by-id" autowiring: a side-effect free variant of it based on the class<>id convention
* 3.2:
[Yaml] CS
[DI] Fix PhpDumper generated doc block
#20411 fix Yaml parsing for very long quoted strings
[Workflow] add Phpdoc for better IDE support
fix package name in conflict rule
improve message when workflows are missing
[Doctrine Bridge] fix priority for doctrine event listeners
Use PHP functions as array_map callbacks when possible
[Validator] revert wrong Phpdoc change
Use proper line endings
* 2.8:
[DI] Fix PhpDumper generated doc block
#20411 fix Yaml parsing for very long quoted strings
[Doctrine Bridge] fix priority for doctrine event listeners
Use PHP functions as array_map callbacks when possible
[Validator] revert wrong Phpdoc change
Use proper line endings
This PR was squashed before being merged into the 3.3-dev branch (closes#21937).
Discussion
----------
[DependencyInjection] Handle void return types in closure-proxy
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
I recently got an error when registering an event listener that specifies a `void` return type. Dumping the container generates a closure proxy that always returns a value, which then conflicts with the return type hint.
E.G the following code is generated (some class names removed for readability)
```
$instance->addListener('kernel.view', /** @closure-proxy ... */ function (...\GetResponseForControllerResultEvent $event): void {
return ${($_ = isset($this->services[listener']) ? $this->services['listener'] : $this->get('listener')) && false ?: '_'}->onKernelView($event);
}, 128);
```
This then causes the error `A void function must not return a value in ...`
So void return types should be handled by removing the `return` inside the closure
Commits
-------
a5c5ad1 [DependencyInjection] Handle void return types in closure-proxy
This PR was merged into the 3.3-dev branch.
Discussion
----------
Fix DI test
| Q | A
| ------------- | ---
| Branch? | master
| Tests pass? | yes
Should fix appveyor/travis builds
Commits
-------
8740e44086 Fix DI test
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] make the service container builder register its own self referencing definition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Commits
-------
9c97496b5f [DependencyInjection] make the service container builder register the definition of its related service container service (and aliases) in order to make compiler passes be able to reference the special service_container service.
* 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 3.3-dev branch.
Discussion
----------
[DI] Allow to count on lazy collection arguments
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/21450#issuecomment-275931764
| License | MIT
| Doc PR | todo (with https://github.com/symfony/symfony-docs/issues/7336)
When using the new iterator feature of the DI component to lazy load collection, we always know the number of arguments in the collection (only the invalidBehavior set to `IGNORE_ON_INVALID_REFERENCE` may change this number). So we are able to generate and use a `RewindableGenerator` implementing `\Countable` by computing this value ahead.
So, in a service accepting `array|iterable`, like in the `GuardAuthenticationListener` (see #21450):
```php
class GuardAuthenticationListener implements ListenerInterface
{
private $guardAuthenticators;
/**
* @param iterable|GuardAuthenticatorInterface[] $guardAuthenticators The authenticators, with keys that match what's passed to GuardAuthenticationProvider
* @param LoggerInterface $logger A LoggerInterface instance
*/
public function __construct($guardAuthenticators, LoggerInterface $logger = null)
{
// ...
}
public function handle(GetResponseEvent $event)
{
if (null !== $this->logger) {
$context = array()
if (is_array($this->guardAuthenticators) || $this->guardAuthenticators instanceof \Countable) {
$context['authenticators'] = count($this->guardAuthenticators);
}
$this->logger->debug('Checking for guard authentication credentials.', $context);
}
// ...
}
}
```
we still keep the ability to call count without loosing the lazy load benefits.
Commits
-------
f23e460 [DI] Allow to count on lazy collection arguments
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Remove synthetic services from methodMap + generated methods
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
For synthetic services, the generated methods are just dead code to fill opcache ;)
And having them in "methodMap" prevents using the property for checking if a service comes from a (non-synthetic) definition or not.
This prepares some changes that we'd like to do in 4.0, see #19668.
Commits
-------
c1e1e999f3 [DI] Remove synthetic services from methodMap + generated methods