* 3.4:
[DI] Turn services and aliases private by default, with BC layer
[WebProfiler] Fix z-index for pinned AJAX block
Require v3.4+ of the var-dumper component
* 3.4:
Do not display short exception trace for built-in console exceptions
Deprecated the web_profiler.position option
[DI] rename ResolveDefinitionTemplatesPass to ResolveChildDefinitionsPass
Throw a meaningful exception when an undefined user provider is used inside a firewall
[DI] Allow processing env vars
* 3.4:
Improved the design of the redirection method in the web toolbar
Mark SemaphoreStore::isSupported() as internal
[DI] Add ContainerInterface::IGNORE_ON_UNINITIALIZED_REFERENCE
[FrameworkBundle] Fix form conflict rule
[Security] add impersonator_user to "User was reloaded" log message
[DI] Add upgrade note about case insenstive params
add (pdo|chain) cache (adapter|simple) prune method
Update NoSuchPropertyException message for writeProperty
[Routing] added the possibility to define a prefix for all routes of a controller
[DI] Don't track merged configs when the extension doesn't expose it
[Cache] Use namespace versioning for backends that dont support clearing by keys
[VarDumper] add force-collapse/expand + use it for traces
* 3.4: (38 commits)
Fix merge
[Lock] Expose an expiringDate and isExpired method in Lock
[VarDumper] fix DateCasterTest
[config] Add ability to deprecate a node
feature #22382 [config] Add abbitily to deprecate a node (Nyholm, fabpot, sanpii)
Fix segfault in period caster
Create an interface for TranslationReader and moved TranslationLoader to Translation component
Always require symfony/polyfill-apcu to provide APCuIterator everywhere
[Lock] Fix some tests that require pcntl_sigwaitinfo() function
bumped Symfony version to 3.3.9
updated VERSION for 3.3.8
updated CHANGELOG for 3.3.8
[DI] Fix tracking env var placeholders nested in object graphs
bumped Symfony version to 3.3.8
updated VERSION for 3.3.7
updated CHANGELOG for 3.3.7
Add period caster
[DI] improve psr4-based service discovery with namespace option
[DI] Fix tracking env vars when merging configs (bis)
removed obsolete comment
...
* 3.4:
[Console] Add protected static $defaultName to set the default name of a Command
removed sf2 references
[Console] Allow commands to provide a default name for compile time registration
[DI] Case sensitive parameter names
* 3.4:
Made some SecurityBundle tests case-insensitive to prepare for future Symfony versions
[Console] Added a case-insensitive fallback for console command names
fix merge
[DI] Fix dumping abstract with YamlDumper
restrict reflection doc block
[DI] Fix YamlDumper not dumping abstract and autoconfigure
* 3.4: (23 commits)
[DI] Allow dumping inline services in Yaml
fixed CS
[2.8] Modify 2.8 upgrade doc - key option is deprecated.
Fix lock failling test
[Debug] Correctly detect methods not from the same vendor
[HttpKernel] Deprecated commands auto-registration
Fix minors in date caster
[FrameworkBundle] Catch Fatal errors in commands registration
[Debug] Detect internal and deprecated methods
[Profiler] Make the validator toolbar item consistent with the form one
[DebugBundle] Reword an outdated comment about var dumper wiring
updated CHANGELOG
[HttpFoundation] Remove length limit on ETag
[DI] Fix some docblocks
[DI] Fix some docblocks
Fixed the exception page design in responsive mode
[Console] Log exit codes as debug messages instead of errors
Fixed UPGRADE-4.0 about Container::set
Ignore memcached missing key error on dession destroy
[FrameworkBundle] Allow micro kernel to subscribe events easily
...
This PR was squashed before being merged into the 3.4 branch (closes#22187).
Discussion
----------
[DependencyInjection] Support local binding
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/22167, #23718
| License | MIT
| Doc PR |
> A great idea came out on Slack about local bindings.
> We could allow injecting services based on type hints on a per service/file basis:
> ```yml
> services:
> _defaults:
> bind:
> BarInterface: '@usual_bar'
>
> Foo:
> bind:
> BarInterface: '@alternative_bar'
> $quz: 'quzvalue'
> ```
>
> This way, `@usual_bar` will be injected in any parameter type hinted as `BarInterface` (in a constructor or a method signature), but only for this service/file.
> Note that bindings could be unused, giving a better solution than https://github.com/symfony/symfony/pull/22152 to https://github.com/symfony/symfony/pull/21711.
>
> As named parameters are usable in arguments, bindings could be usable in arguments too:
> ```yml
> services:
> Foo:
> arguments:
> BarInterface: '@bar'
> ```
~Named parameters aren't supported yet.~
Edit:
> Note that bindings could be unused
Current behavior is throwing an exception when a binding is not used at all, in no services of a file if it was inherited from `_defaults` or in no services created from a prototype.
It will pass if the bindings are all used in at least one service.
Commits
-------
81f2652 [DependencyInjection] Support local binding
* 3.4: (22 commits)
Fix lazy commands registration
[TwigBridge] deprecate TwigRenderer
[FrameworkBundle] Set default public directory on install assets
[Security] Fix wrong term in UserProviderInterface
[HttpFoundation] Set meta refresh time to 0 in RedirectResponse content
disable inlining deprecated services
[Stopwatch] Fix precision for root section
[Cache] add constructor docblocks for clarity
[WebServerBundle] allowed public/ root directory to be auto-discovered along side web/
[WebServerBundle] remove duplicate code
[SecurityBundle] Clarify deprecation in UserPasswordEncoderCommand::getContainer
[Profiler][Validator] ValidatorDataCollector: use new DataCollector::getCasters() method
[Profiler] Fix data collector getCasters() call
[VarDumper] Added setMinDepth to VarCloner
remove symfony/process suggestion
[DI] Remove unused dynamic property
[Cache] add constructor docblocks for clarity
[Security] validate empty passwords again
[Process] Fixed issue between process builder and exec
non-conflicting anonymous service ids across files
...
* 3.3:
[Profiler] Fix data collector getCasters() call
remove symfony/process suggestion
[DI] Remove unused dynamic property
[Process] Fixed issue between process builder and exec
non-conflicting anonymous service ids across files
* 3.4:
Add TokenProcessor
[DI] Handle root namespace in service definitions
Add support for command lazy-loading
Use rawurlencode() to transform the Cookie into a string
[TwigBundle] Added a RuntimeExtensionInterface to take advantage of autoconfigure
[Process] Fix parsing args on Windows
Add exculde verbosity test
[HttpKernel][VarDumper] Truncate profiler data & optim perf
[DI] Allow imports in string format for YAML
[Validator] Allow to use a property path to get value to compare in comparison constraints
[Security] Fix authentication.failure event not dispatched on AccountStatusException
add option to define the access decision manager
Add support for doctrin/dbal 2.6 types
* 3.4:
Fix optional cache warmers are always instantiated whereas they should be lazy-loaded
add some \ on PHP_VERSION_ID for 2.8
[Di] Remove closure-proxy arguments
[PropertyInfo][DoctrineBridge] The bigint Doctrine's type must be converted to string
Now that inherit_tags has been removed, 3.3 has the same functionality as 3.2: tags
are *never* cascaded from parent to child (but you tags do inherit from defaults
to a service and instanceof to a service).
This PR was merged into the 3.3-dev branch.
Discussion
----------
Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes (removing risky behavior)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | see #22530
| License | MIT
| Doc PR | n/a
This PR *prohibits* using `autoconfigure`, `_instanceof` and `_defaults` for ChildDefinition.
Additionally, I added many "integration" test cases: we need to test and prove all edge cases. These are in the `integration/` directory: the `main.yml` file is parsed and compared to `expected.yml`. Both are in YAML to ease comparing the before/after. We need to check these out and make sure they're right and we're not missing anything else.
This PR removes MANY of the "wtf" cases, but there are still 4 that I know of... and of course they all deal with parent-child stuff :).
A) [MAJOR] [autoconfigure_parent_child_tags](https://github.com/symfony/symfony/pull/22563/files#diff-fd6cf15470c5abd40156e4e7dc4e7f6d) `instanceof` tags from autoconfigure are NEVER applied to the child (you can't set `autoconfigure` directly on a Child, but you still can set it on a parent and inherit it... sneaky). We could throw an Exception I suppose to prevent this `autoconfigure` from cascading from parent to child... but it's tricky due to `instanceof`.
B( [MAJOR] [instanceof_parent_child](https://github.com/symfony/symfony/pull/22563/files#diff-14666e9a25322d44b3c2c583b6814dc2) `instanceof` tags that are applied to the parent, are not applied to the child. Again, you can't set `instanceof` directly on a Child, but you *can* set it on a parent, and have that cascade to the child. Like before, we could maybe throw an exception to prevent this.
C) [MINOR] ([autoconfigure_child_not_applied](https://github.com/symfony/symfony/pull/22563/files#diff-3372a1dcaf3af30d14a7d0a6c8bfa988)) automatic `instanceof` will not be applied to the child when the parent class has a different (non-instanceof-ed) class. If we could throw an exception for (A), then it would cover this too.
D) `_tags` from defaults are never used (unless you have inherit_tags) - fixed in #22530
A, B & C are effectively caused by there being a "sneaky" way to re-enable `autoconfigure` and `instanceof` for ChildDefinition... which opens up wtf cases.
## Wait, why not support `_defaults`, `autoconfigure` and `_instanceof` for child definitions?
1 big reason: reduction of wtf moments where we arbitrarily decide override logic. PLUS, since `_defaults`, `instanceof` and `autoconfigure` *are* applied to parent definitions, in practice (other than tags), this makes no difference: the configuration will still pass from parent down to child.
Also, using parent-child definitions is already an edge case, and this *simply* prevents *just* those services from using the new features.
## Longer reasons why
The reason behind this is that parent-child definitions are a different mechanism for "inheritance"
than `_instanceof` and `_defaults`... creating some edge cases when trying to figure out which settings "win". For example:
```yml
# file1.yml
services:
_defaults:
public: false
ChildService:
parent: parent_service
# file2.yml
services:
_defaults:
public: true
ParentService: ~
```
Is `ChildDefinition` `public: true` (so the parent
overrides the child, even though it only came from _defaults) or `public: false` (where
the child wins... even though it was only set from its _defaults)?
Or, if ParentService is explicitly set to `public: true`, should that override the `public: false` of ChildService (which it got from its `_defaults`)? On one hand, ParentService is being explicitly
set. On the other hand, ChildService is explicitly in a file settings `_defaults` `public: false`
There's no correct answer.
There are also problems with `_instanceof`. The importance goes:
> defaults < instanceof < service definition
But how do parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
Commits
-------
a943b96d42 Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
Also, not allowing arguments or method calls for autoconfigure. This is a safety
mechanism, since we don't have merging logic. It will allow us to add this in the
future if we want to.
The reason is that parent-child definitions are a different mechanism for "inheritance"
than instanceofConditionas and defaults... creating some edge cases when trying to
figure out which settings "win". For example:
Suppose a child and parent definitions are defined in different YAML files. The
child receives public: false from its _defaults, and the parent receives public: true
from its _defaults. Should the final child definition be public: true (so the parent
overrides the child, even though it only came from _defaults) or public: false (where
the child wins... even though it was only set from its _defaults). Or, if the parent
is explicitly set to public: true, should that override the public: false of the
child (which it got from its _defaults)? On one hand, the parent is being explicitly
set. On the other hand, the child is explicitly in a file settings _defaults public
to false. There's no correct answer.
There are also problems with instanceof. The importance goes:
defaults < instanceof < service definition
But how does parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
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[]
