This PR was merged into the 3.4 branch.
Discussion
----------
Address deprecation of ReflectionType::getClass()
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
Calling `ReflectionType::getClass()` will trigger a deprecation warning on php 8. This PR switches to `getType()` if available.
Commits
-------
53b1677a4e Address deprecation of ReflectionType::getClass().
This PR was merged into the 3.4 branch.
Discussion
----------
[VarDumper] ReflectionFunction::isDisabled() is deprecated
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
See php/php-src#5473. Calling `ReflectionFunction::isDisabled()` is pointless on php 8 and doing so triggers a deprecation warning.
Someone who is more familiar with that component might want to have a second look on this PR. I'm not really sure if this is the right way to fix the issue.
Commits
-------
1da347e5ba [VarDumper] ReflectionFunction::isDisabled() is deprecated.
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Catch expected ValueError
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
`mb_check_encoding()` raises a `ValueError` on php 8 if an invalid encoding was passed. The validator that was patched here is expected to fail gracefully in that situation. This PR restores that behavior under php 8.
Maybe we can reconsider this behavior for Symfony 5.2. It feels a bit odd to me because we swallow a potential misconfiguration of the validator.
Commits
-------
8f3f67f82a [Validator] Catch expected ValueError.
This PR was merged into the 4.4 branch.
Discussion
----------
[Cache][HttpClient] Made method signatures compatible with their corresponding traits
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
Apparently, php 8 is less forgiving about method signature differences between a trait and the class that uses the trait. This PR makes minimal adjustments to get rid of fatal errors triggered by php 8.
Commits
-------
6fda276feb Made method signatures compatible with their corresponding traits.
This PR was merged into the 3.4 branch.
Discussion
----------
[DomCrawler] Catch expected ValueError
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
`mb_convert_encoding()` raises a `ValueError` on php 8 if an unknown character set is passed. This causes trouble with the whole test suite because the temporary error handler is not deregistered in that case.
Since the previously raised warning was actively ignored by that error handler, I'm now ignoring the `ValueError` as well. Also, I've wrapped the `restore_error_handler()` call into a `finally` statement to make the whole construct a bit more robust.
Commits
-------
b1db13728b [DomCrawler] Catch expected ValueError.
This PR was merged into the 3.4 branch.
Discussion
----------
[PropertyAccess] Parse php 8 TypeErrors correctly
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
The wording of `TypeError` messages has changed in php 8. Since `PropertyAccessor` parses those messages, the logic needed some adjustments.
Commits
-------
7100c3ce1b [PropertyAccess] Parse php 8 TypeErrors correctly.
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug] php 8 does not pass $context to error handlers
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
php 8 will call error handlers without the optional `$context` parameter. Thus, error handlers that make that parameter mandatory will break.
Commits
-------
593897c9e1 [Debug] php 8 does not pass $context to error handlers.
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[BrowserKit] Raw body with custom Content-Type header
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
Currently, if you try to send POST/PUT request with custom `Content-Type` header and specified body, the real request will contain `text/plain` content type.
Following code
```php
$client->request(
'POST',
'/url',
[],
[],
[
'CONTENT_TYPE' => 'application/json'
],
'{"foo":"bar"}'
);
```
produces next request
```
POST /
Content-Type: text/plain; charset=utf-8
{"foo":"bar"}
```
With this fix, the request will be
```
POST /
Content-Type: application/json
{"foo":"bar"}
```
Commits
-------
d2dd92be77 [BrowserKit] Raw body with custom Content-Type header
This PR was merged into the 3.4 branch.
Discussion
----------
UploadedFile minor fixes
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | none <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | no
According to the [constructor assignments](cb7e78c809/src/Symfony/Component/HttpFoundation/File/UploadedFile.php (L60)), properties `$originalName` and `$mimeType` are never null in `UploadedFile`, so `getClientOriginalName()` and `getClientMimeType()` always return `string`. Also `$test` does not need a default value because it's always set in the constructor.
Commits
-------
eb8d626c27 Properties $originalName and $mimeType are never null in UploadedFile
This PR was merged into the 3.4 branch.
Discussion
----------
[Intl] Fix call to ReflectionProperty::getValue() for static properties
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
When we call `ReflectionProperty::getValue()` for a static property, we don't need to pass any arguments. The code that was fixed here raised a `TypeError` on php 8 because the argument has to be an object now.
Commits
-------
d4045897d6 [Intl] Fix call to ReflectionProperty::getValue() for static properties.
This PR was merged into the 3.4 branch.
Discussion
----------
[Config] Removed implicit cast of ReflectionProperty to string
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
PHP 8 does not allow casting `ReflectionProperty` instances to string anymore.
Commits
-------
8adbadede7 [Config] Removed implicit cast of ReflectionProperty to string.
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug] Undefined variables raise a warning in php 8
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
`ErrorHandlerTest` executes code with undefined variables to test how the error handler handles the triggered errors. In php 8.0, the severity and error message for this class of errors has been changed. I've adjusted the test accordingly.
Commits
-------
1d20b514f2 [Debug] Undefined variables raise a warning in php 8.
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Prevent calling method_exists() with non-string values
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
On php 8, `method_exists()` will raise a `TypeError` if the first argument is neither an object or string. We do have a test case that calls the `ControllerResolver` with integer `1` as `$controller`. This test should work as expected again on php 8.
Commits
-------
1bbfdcbb8d [HttpKernel] Prevent calling method_exists() with non-string values.
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug] Skip test that would trigger a fatal error on php 8
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
This PR skips a test of `DebugClassLoader`. The test uses incompatible method signatures in class inheritance to provoke a php warning that should be handled by the debug class loader. On php 8 however, this error is not recoverable anymore, so the tested logic will be obsolete there.
Commits
-------
573d0dd493 [Debug] Skip test that would trigger a fatal error on php 8.
This PR was merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge] fix installing under PHP >= 8
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
[As experimented on Twig](b952011f95), using `simple-phpunit` is not simple enough when testing with PHP 8.
This PR fixes the issue so that we could remove these lines in Twig.
On 3.4 since supporting new versions of PHP is a bugfix according to our policies.
Commits
-------
5aa25ceb41 [PhpUnitBridge] fix installing under PHP >= 8
This PR was merged into the 4.4 branch.
Discussion
----------
Use ">=" for the "php" requirement
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
As explained in https://twitter.com/nicolasgrekas/status/1263023258938548225:
Using `"^7.x"` is our composer.json has been a mistake. We should always use `">=7.x"`! 3 reasons:
1. it's either planned obsolescence xor a strong promise to maintain in the long run. None is sustainable.
2. if you actually end up maintaining in the long run (not by promise but by fact), your latest versions will work with PHP 8 by definition.
3. meanwhile, `"^7.x"` prevented all your ecosystem from experimenting with PHP 8, which means they increased the workload on *you* the core maintainer.
Conclusion: always use `">="` for the `"php"` requirement. Hope for the best (it mostly happens) and enable your community to experiment with the next major asap without adding useless impediments.
Commits
-------
f8aa0873cf Use ">=" for the "php" requirement
This PR was merged into the 4.4 branch.
Discussion
----------
[Intl] bump icu 67.1
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix #... <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/releases):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained 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 branch master.
-->
Commits
-------
920e319051 bump icu 67.1
Alexander M. Turek
Nicolas Grekas
Fabien Potencier
Oleksii Zhurbytskyi
Thibaut Salanon
Christian Flothmann
Roland Franssen