* 3.4: (24 commits)
Apply php-cs-fixer rule for array_key_exists()
[Security] Change FormAuthenticator if condition
handles multi-byte characters in autocomplete
speed up tests running them without debug flag
[Translations] added missing Croatian validators
Fix getItems() performance issue with RedisCluster (php-redis)
[VarDumper] Keep a ref to objects to ensure their handle cannot be reused while cloning
IntegerType: reject submitted non-integer numbers
be keen to newcomers
[HttpKernel] Fix possible infinite loop of exceptions
fixed CS
[Validator] Added missing translations for Afrikaans
do not validate non-submitted form fields in PATCH requests
Update usage example in ArrayInput doc block.
[Console] Prevent ArgvInput::getFirstArgument() from returning an option value
[Validator] Fixed duplicate UUID
fixed CS
[EventDispatcher] Fix unknown priority
Avoid mutating the Finder when building the iterator
[Validator] Add the missing translations for the Greek (el) locale
...
* 3.4:
Fix Clidumper tests
Enable the fixer enforcing fully-qualified calls for compiler-optimized functions
Apply fixers
Disable the native_constant_invocation fixer until it can be scoped
Update the list of excluded files for the CS fixer
* 2.8:
Fix Clidumper tests
Enable the fixer enforcing fully-qualified calls for compiler-optimized functions
Apply fixers
Disable the native_constant_invocation fixer until it can be scoped
Update the list of excluded files for the CS fixer
* 3.4:
do not mock the session in token storage tests
[DependencyInjection] resolve array env vars
Add Occitan plural rule
Fix security/* cross-dependencies
[Lock] Skip test if posix extension is not installed
[DI] Allow defining bindings on ChildDefinition
use strict compare in url validator
Disallow illegal characters like "." in session.name
[HttpKernel] do file_exists() check instead of silent notice
fix rounding from string
* 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
...
* 3.3:
fixed CS
[2.8] Modify 2.8 upgrade doc - key option is deprecated.
[DebugBundle] Reword an outdated comment about var dumper wiring
[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
bumped Symfony version to 3.2.14
updated VERSION for 3.2.13
updated CHANGELOG for 3.2.13
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).
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.
The DefinitionDecorator class does not deal with decorated services. It
reflects a parent-child-relationship between definitions instead. To
avoid confusion, this commit deprecates the existing DefinitionDecorator
class and introduces a new ChildDefinition class as replacement.
