This PR was squashed before being merged into the 3.3-dev branch (closes#21978).
Discussion
----------
[DoctrineBridge][Routing] Require PSR-11 container instead of Symfony container
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
The changed classes can easily use PSR-11 container instead of normal symfony container.
I didn't change any classes that have the `$container` property as protected (for example `Symfony\Bundle\FrameworkBundle\Translation\Translator`) because I'm unsure whether that would be considered a BC break. Let me know if you want me to change such classes as well.
Commits
-------
0043653ea8 [DoctrineBridge][Routing] Require PSR-11 container instead of Symfony container
This PR was merged into the 3.2 branch.
Discussion
----------
[VarDumper] Add missing isset() checks in some casters
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21943
| License | MIT
| Doc PR | -
As spotted by @lyrixx, this is what's causing high mem use on 3.2.
Fix coming to 2.7 (which has very different code base, thus dedicated PR).
Commits
-------
8f0edfb [VarDumper] Add missing isset() checks in some casters
This PR was squashed before being merged into the 2.7 branch (closes#21957).
Discussion
----------
[Form] Choice type int values (BC Fix)
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21952
| License | MIT
#21267 unnecessarily forced all choice values to be strings, this was a BC braking change.
Everything can work fine if they are strings or ints. specifically the issue was because `array_flip` is used on the `choices` array, but this function will work fine with ints as well as strings.
Normally, when using HTML forms all data comes as strings, but the `symfony/form` component has use cases beyond this, specifically, I use it with JSON data, where valid values for a `ChoiceType` might not be strings.
Commits
-------
ed211e9c74 [Form] Choice type int values (BC Fix)
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection Remove duplicated code
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- 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 |
| License | MIT
| Doc PR |
<!--
- Bug fixes must be submitted against the lowest branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
Arrays are already supported by `YamlFileLoader::resolveServices()` so there's no need to duplicate code.
Commits
-------
1bac3d722d [DependencyInjection Remove duplicated code
This PR was merged into the 3.3-dev branch.
Discussion
----------
[PropertyInfo] Move CHANGELOG.md to the root
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- 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 |
| License | MIT
| Doc PR |
Moves the CHANGELOG of the PropertyInfo Component from the DependencyInjection subdirectory to the component's root.
Commits
-------
d5d3f4285b [PropertyInfo] Move CHANGELOG.md to the root
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Workflow] Added fluent interface to the DefinitionBuilder
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
---
It seems more logic to me to have this fluent interface.
Commits
-------
4c8963c6ff [Workflow] Added fluent interface to the DefinitionBuilder
This PR was squashed before being merged into the 3.3-dev branch (closes#21933).
Discussion
----------
[FrameworkBundle][Workflow] Add a way to enable the AuditTrail Logger
| 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 will increase the visibility of the Listener. We could encourage people to use at least `%kernel.debug%` value.
---
Note for the merge: There are two commits, this is done on purpose (2 different things, but easier to do only one PR)
Commits
-------
633c0393b3 [Workflow] Added the workflow name in log generated by AuditTrailListener
b786bccb3a [FrameworkBundle][Workflow] Add a way to enable the AuditTrail Logger
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.2 branch.
Discussion
----------
Use PHPUnit 5.4 instead of 5.3
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
PHPUnit 5.3 doesn't have the forward compatibility layer for PHPUnit 6 so that `PHPUnit\Framework\TestCase` can be used instead of `PHPUnit_Framework_TestCase`.
This generates an error when upgrading to Symfony 3.2.5 without forcing the `SYMFONY_PHPUNIT_VERSION` const:
```
Class 'PHPUnit\Framework\TestCase' not found in vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Test/KernelTestCase.php on line 25
```
This was introduced by c9684ad31f (from https://github.com/symfony/symfony/pull/21564) in 3.2.5
(Discussion started on Slack: https://symfony-devs.slack.com/archives/support/p1489058629011510)
Commits
-------
fca16ba Use PHPUnit 5.4 instead of 5.3
PHPUnit 5.3 doesn't have the forward compatibility layer for PHPUnit 6 so that `PHPUnit\Framework\TestCase` can be used instead of `PHPUnit_Framework_TestCase`.
This generates an error when upgrading to Symfony 3.2.5 without forcing the `SYMFONY_PHPUNIT_VERSION` const:
```
Class 'PHPUnit\Framework\TestCase' not found in vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Test/KernelTestCase.php on line 25
```
This was introduced by c9684ad31f in 3.2.5
* 3.2:
[Workflow] Delete dead code
Rename StackOverflow to Stack Overflow
[travis] Test with hhvm 3.18
[Workflow] Fixed marking state on leave and enter events
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Fix autoloader in insulated clients
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Related to the deprecation of the class loader component:
the `Client` already uses this code in `HttpKernel`, but `FrameworkBundle` is missing the same update.
Spotted while debugging the hhvm 3.18 issue (the chain is: `ComposerResource` sees different vendors, thus says the kernel cache is not fresh, thus it is rebuild, thus we hit https://github.com/facebook/hhvm/issues/7722).
Commits
-------
414ac5d976 [FrameworkBundle] Fix autoloader in insulated clients
This PR was merged into the 2.7 branch.
Discussion
----------
[travis] Test with hhvm 3.18
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21900
| License | MIT
| Doc PR | -
Needs #21922 on master to be green also.
Works around facebook/hhvm#7722.
Commits
-------
7f1f0cb630 [travis] Test with hhvm 3.18
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Workflow] Added the workflow name to all events dispatched
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21818
| License | MIT
| Doc PR | -
Commits
-------
b3400c7312 [Workflow] Added the workflow name to all events dispatched
This PR was merged into the 3.2 branch.
Discussion
----------
[Workflow] Delete dead code
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | "no"
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
---
Me (and all reviewers ;) ) totally miss this class. It has never been used and there are no reason to use it anyway. It's just a relic from the designing of the Component. Sorry.
I really don't think it deserves a deprecation as the component is quite new, and it is really some dead code.
Commits
-------
28e85cc32a [Workflow] Delete dead code
This PR was merged into the 3.2 branch.
Discussion
----------
[Workflow] Fixed marking state on leave and enter events
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | related to https://github.com/symfony/symfony-docs/pull/7528
It seems weird to me to dispatch an event while the marking is not yet marked by the new places.
The event is still "marked" by old places when leaving occurs, my guess is that the symmetry should be mirrored.
Do you agree? Should I add a test?
Commits
-------
175858a67e [Workflow] Fixed marking state on leave and enter events
