* 3.3:
[DI] Dont resolve envs in service ids
Add tests proving it can load annotated files
[WebProfilerBundle] Reset letter-spacing in toolbar
Prefer overflow-wrap to word-break
[Routing] Fix "config-file-relative" annotation loader resources
Make search in debug:container command case-insensitive
`resolveEnvPlaceholders` will return a mixed value
* 3.3:
[Serializer] Fix extra attributes when no group specified
[Intl] Make intl-data tests pass and save language aliases again
[Console] Fix CommandTester::setInputs() docblock
[Serializer] readd default argument value
[VarDumper] fix trailling comma when dumping an exception
Remove useless docblocks
[FrameworkBundle] Fix docblocks
[PropertyInfo] Remove useless docblocks
* 2.8:
[CS][2.7] yoda_style, no_unneeded_curly_braces, no_unneeded_final_method, semicolon_after_instruction
[Filesystem] mirror - fix copying content with same name as source/target.
.php_cs.dist - simplify config
[WebProfilerBundle] fixed TemplateManager when using Twig 2 without compat interfaces
* 3.3: (27 commits)
Always require symfony/polyfill-apcu to provide APCuIterator everywhere
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
[DI] Fix tracking env vars when merging configs (bis)
removed obsolete comment
install PHPUnit 6 on PHP 7.2
[Cache] Use zend.detect_unicode instead of zend.multibyte
Fix case sensitive typo in use class name
[VarDumper] Enhance docblock to tell about AbstractDumper::dumpLine(-1)
[Debug] Remove false-positive check in DebugClassLoader
[Validator] Fix use of GroupSequenceProvider in child classes
Change number PHPDoc type to int|float
[Cache] Workaround zend.detect_unicode + zend.multibyte
[VarDumper] Strengthen dumped JS
[VarDumper] Strengthen dumped JS
...
* 3.3:
[Dotenv] Get env using $_SERVER to work with fastcgi_param and workaround thread safety issues
[Dotenv][WebServerBundle] Override previously loaded variables
[DI] Use GlobResource for non-tracked directories
[WebProfilerBundle] Re add missing link to the controller
This PR was merged into the 3.3 branch.
Discussion
----------
[DI] Use GlobResource for non-tracked directories
| Q | A
| ------------- | ---
| Branch? | 3.3
| 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 noticed that some of my excluded directories are still tracked by the container and changes to files inside them make it recompile. This brought me to the `$trackContents || is_dir($path)` line introduced in #21505.
Commits
-------
048eb18 [DI] Use GlobResource for non-tracked directories
* 3.3:
[VarDumper] Fix tests with phpredis 3.1.3
[DI] Fix reading env vars from fastcgi params
Allow phpdocumentor/reflection-docblock 4.
[VarDumper] play nice with open_basedir when looking for composer.json
* 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
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.