Update to Symfony 6.3

The last submitted patch, 2: 3338328-2.patch, failed testing. View results →

Rerolled and removed "minimum-stability": "beta" from two components' composer.json file.

The last submitted patch, 4: 3338328-3.patch, failed testing. View results →

This revealed no new deprecations yet, so I think we can just leave this for a month or more.

Let's try again.

+------------------------------------+--------+-----------+
| Production Changes                 | From   | To        |
+------------------------------------+--------+-----------+
| symfony/console                    | v6.2.5 | 6.3.x-dev |
| symfony/dependency-injection       | v6.2.6 | 6.3.x-dev |
| symfony/deprecation-contracts      | v3.2.0 | v3.2.1    |
| symfony/error-handler              | v6.2.5 | 6.3.x-dev |
| symfony/event-dispatcher           | v6.2.5 | 6.3.x-dev |
| symfony/event-dispatcher-contracts | v3.2.0 | v3.2.1    |
| symfony/http-foundation            | v6.2.6 | 6.3.x-dev |
| symfony/http-kernel                | v6.2.6 | 6.3.x-dev |
| symfony/mime                       | v6.2.5 | 6.3.x-dev |
| symfony/process                    | v6.2.5 | 6.3.x-dev |
| symfony/routing                    | v6.2.5 | 6.3.x-dev |
| symfony/serializer                 | v6.2.5 | 6.3.x-dev |
| symfony/service-contracts          | v3.2.0 | v3.2.1    |
| symfony/string                     | v6.2.5 | v6.2.8    |
| symfony/translation-contracts      | v3.2.0 | v3.2.1    |
| symfony/validator                  | v6.2.5 | 6.3.x-dev |
| symfony/var-dumper                 | v6.2.5 | 6.3.x-dev |
| symfony/var-exporter               | v6.2.5 | v6.2.8    |
| symfony/yaml                       | v6.2.5 | 6.3.x-dev |
| symfony/polyfill-php83             | NEW    | v1.27.0   |
+------------------------------------+--------+-----------+

+------------------------+--------+-----------+
| Dev Changes            | From   | To        |
+------------------------+--------+-----------+
| symfony/browser-kit    | v6.2.5 | 6.3.x-dev |
| symfony/css-selector   | v6.2.5 | 6.3.x-dev |
| symfony/dom-crawler    | v6.2.5 | 6.3.x-dev |
| symfony/filesystem     | v6.2.5 | 6.3.x-dev |
| symfony/finder         | v6.2.5 | 6.3.x-dev |
| symfony/lock           | v6.2.5 | 6.3.x-dev |
| symfony/phpunit-bridge | v6.2.5 | 6.3.x-dev |
+------------------------+--------+-----------+

ExecutionContext has added return types. It's tagged @internal so Symfony can do this in a minor, but we extend it anyway, so we have to match.

This also reminded me of 📌 Remove unused Symfony 2.x methods from ExecutionContext Fixed

Adding the deprecation skip from #3351556-8: Update dependencies for Drupal 10.1 → to this patch would help reduce the noise?

https://github.com/symfony/symfony/releases/tag/v6.3.0-BETA1

+---------------------------------+--------+--------------+
| Production Changes              | From   | To           |
+---------------------------------+--------+--------------+
| symfony/console                 | v6.2.8 | v6.3.0-BETA1 |
| symfony/dependency-injection    | v6.2.8 | v6.3.0-BETA1 |
| symfony/error-handler           | v6.2.7 | v6.3.0-BETA1 |
| symfony/event-dispatcher        | v6.2.8 | v6.3.0-BETA1 |
| symfony/http-foundation         | v6.2.8 | v6.3.0-BETA1 |
| symfony/http-kernel             | v6.2.8 | v6.3.0-BETA1 |
| symfony/mime                    | v6.2.7 | v6.3.0-BETA1 |
| symfony/process                 | v6.2.8 | v6.3.0-BETA1 |
| symfony/psr-http-message-bridge | v2.1.4 | v2.2.0       |
| symfony/routing                 | v6.2.8 | v6.3.0-BETA1 |
| symfony/serializer              | v6.2.8 | v6.3.0-BETA1 |
| symfony/validator               | v6.2.8 | v6.3.0-BETA1 |
| symfony/var-dumper              | v6.2.8 | v6.3.0-BETA1 |
| symfony/var-exporter            | v6.2.8 | v6.2.10      |
| symfony/yaml                    | v6.2.7 | v6.3.0-BETA1 |
| symfony/polyfill-php83          | NEW    | v1.27.0      |
+---------------------------------+--------+--------------+

+------------------------+--------+--------------+
| Dev Changes            | From   | To           |
+------------------------+--------+--------------+
| symfony/browser-kit    | v6.2.7 | v6.3.0-BETA1 |
| symfony/css-selector   | v6.2.7 | v6.3.0-BETA1 |
| symfony/dom-crawler    | v6.2.8 | v6.3.0-BETA1 |
| symfony/filesystem     | v6.2.7 | v6.3.0-BETA1 |
| symfony/finder         | v6.2.7 | v6.3.0-BETA1 |
| symfony/lock           | v6.2.8 | v6.3.0-BETA1 |
| symfony/phpunit-bridge | v6.2.7 | v6.3.0-BETA1 |
+------------------------+--------+--------------+

As said by @longwave in #7 📌 Update to Symfony 6.3 Fixed :

Symfony\Component\Validator\Context\ExecutionContextInterface has added return types. The methods are tagged @internal so Symfony can do this in a minor, but we extend it anyway, so we have to match

So I added the return type PHPStan wanted.
Let's see where that gets us.

Thanks! No need to postpone now the beta is out - we can release Drupal 10.1.0-beta1 on a beta or RC of Symfony.

The last submitted patch, 14: 3338328-14.patch, failed testing. View results →

So what's our strategy here?

- Ignore all deprecations with one "mega" reg-ex in core/.deprecation-ignore.txt
- Ignore all deprecations with their own reg-ex in core/.deprecation-ignore.txt, so we can tackle them individually in issues
- Try to fix all and everything in here?

Looks like this changes will break a lot of contrib as well, having tons of deprecation messages is worst we can expect in 10.1 release

As I got the most serious effect will get serializers (adding array return type)

The most useless (contr-productive) is void types

1x: Method
"Symfony\Component\DependencyInjection\ContainerInterface::set()" might add
"void" as a native return type declaration in the future. Do the same in
implementation "Drupal\Component\DependencyInjection\Container" now to avoid
errors or add an explicit @return annotation to suppress this message.

1x: Method
"Symfony\Component\DependencyInjection\ContainerBuilder::set()" might add
"void" as a native return type declaration in the future. Do the same in
child class "Drupal\Core\DependencyInjection\ContainerBuilder" now to avoid
errors or add an explicit @return annotation to suppress this message.

So...

IIRC, adding a return type is a BC Break
Adding an explicit @return void makes coder sad:
If there is no return value for a function, there must not be a @return tag

Looks like we need to ignore a lot of deprecation messages until D11?

We need to check what will happen to subclasses in contrib/custom code - we need to ensure they are notified correctly so they can add the return types now, and then we can do the same in Drupal 11. Not sure whether that means adding exact deprecation skips, or using @return and adding ignores for Coder, or something else.

For the normalizers/denormalizers I would think we can probably make the change directly since those aren't supposed to be extended, but whether that is actually true or not is a different question.

but whether that is actually true or not is a different question.

http://codcontrib.hank.vps-private.net/search?text=Drupal%5Cserializatio...

Third normalizer I've randoml put through Hank has 2 Contrib Module extending it.

For the normalizers/denormalizers I would think we can probably make the change directly since those aren't supposed to be extended

Added a (very naive) MR for this.

AFAICT we're replacing our

protected $supportedInterfaceOrClass

with Symfony's public function getSupportedTypes(?string $format): array.
If that is the case can/should we try to deprecate our class property $supportedInterfaceOrClass?

Two more questions in the MR.

https://github.com/symfony/symfony/releases/tag/v6.3.0-BETA2, updated MR.

MR is not mergeable somehow

MR is not mergeable somehow

Sorry, crappy rebaser at weekend work there...
Should be fixed now.

Looks like this is what's left when I aggregate the deprecation messages.

~90% of the changes in the current MR are for https://symfony.com/blog/new-in-symfony-6-3-performance-improvements#imp....
Symfony is now doing what we've been wanting since 2018 — see 🌱 [META] Normalization System: clean up/speed up/provide schema Active . Then Symfony shipped CacheableSupportsMethodInterface which was a step in the right direction — see #3031214-19: Introduce "deterministic" normalizers → .

Now it's finally doing the sensible thing for serializing any slightly complex data structure, of which Drupal has plenty 😅

Great! 👍

Based on https://github.com/symfony/symfony/pull/49291's profiling, I expect this to make complex JSON:API responses significantly faster.

Tagging for release notes and highlights for at least the JSON:API speed improvement.

Attempt to fix doc-blocks

Workaround for phpcs

The last submitted patch, 32: 3338328-32.patch, failed testing. View results →

2 more validators fixed, tests should be green but that means that not all validators are covered by tests

This appears to be adding a ton of deprecation. Should there be an Omni change record for them? Also a ton of phpcs ignore lines. Should that rule just be disabled?

Agreed with #35, however I think we should open a follow-up to deal with the phpcs issue and just press ahead with ignoring here.

Tagging for

+++ b/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/BundleConstraintValidator.php
@@ -12,6 +12,9 @@ class BundleConstraintValidator extends ConstraintValidator {
+   *
+   * phpcs:ignore Drupal.Commenting.FunctionComment.VoidReturn
+   * @return void
    */

Let's open a follow-up, not sure that rule is actually useful if we have to be able to add these.

A single change record for ::hasCacheableSupportsMethod() seems OK although afaict it's really an upstream Symfony deprecation rather than ours, still useful to have the trigger_eror() though.

If we just need the change record here then this is probably more 'needs review'.

I (maybe) see some more NW items:

- What about the open threads on the MR?
- What about

AFAICT we're replacing our

protected $supportedInterfaceOrClass

with Symfony's public function getSupportedTypes(?string $format): array.
If that is the case can/should we try to deprecate our class property $supportedInterfaceOrClass?

Added the change record.

I'm getting confused between the patch and MR.

__NAMESPACE__ vs __CLASS__ this should be __CLASS__ I think.

Deprecating the property I also think we should move to a follow-up since we'll need to decide whether to deprecate or just remove the properties on normalizers.

Could we do something like this, and avoid all the boilerplate on the extending classes?

I think this will be moved vs added boilerplate in the long run so better to just implement the method now.

+++ b/core/modules/link/src/Plugin/Validation/Constraint/LinkNotExistingInternalConstraintValidator.php
@@ -15,6 +15,9 @@ class LinkNotExistingInternalConstraintValidator extends ConstraintValidator {
+   * phpcs:ignore Drupal.Commenting.FunctionComment.VoidReturn
+   * @return void

It needs own issue for coder to dig if the rule valuable

But as this deprecation (requirement to add void) coming from SF at means all validators (at least) need to add this doc-block or :void to method which is no-go as API break

that's why doc-block update needs rector rule or kinda

Change record looks good.

Only other thing I see #34 mentions not all validators are covered. Should we open up follow ups for the ones not covered?

RE #41 I'm sure yes, not every validator used in tests but will fire for contrib/custom code

Opened 📌 Missing test coverage for some validators Active

A reroll was needed due to 📌 Update dependencies for Drupal 10.1 Fixed . Here it is. The way I made it was by applying #34 but without the changes to composer.lock, CoreRecommended/composer.json, and PinnedDevDependencies/composer.json, followed by running composer update drupal/core symfony/*.

AFAICT, this is a clean reroll and ends up with the same state as #34 did. However, marking this as Needs Review so that someone else validates that.

Compared with the version numbers in #34 and reroll seems good.

Still think __NAMESPACE__ needs to be __CLASS__ in the deprecation messages?

Opened 📌 Deprecate ::supportedInterfaceOrClass property on normalizer/denormalizers Fixed for the supportedInterfaceOrClass deprecation.

Still think __NAMESPACE__ needs to be __CLASS__ in the deprecation messages?

Or even better, __METHOD__? This patch changes to that, moves the word "instead" to the end of the sentence, and links to the change record.

++ to #47

Should we wait for next beta?

Should 10.2.x be an option now?

https://www.drupal.org/about/core/policies/core-release-cycles/schedule → says the branch was created.

Unsure why we ended up in patch-land after starting out as an MR, but closed MR to prevent confusion.

Spokje → closed merge request !3907

https://github.com/symfony/symfony/releases/tag/v6.3.0-BETA3

This looks good.

We're holding off tagging the beta until this lands since having it in the beta is more likely to flush out anything unexpected affecting contrib.

I opened 📌 Consider disabling the Drupal.Commenting.FunctionComment.VoidReturn rule Active for the @return void issue.

https://git.drupalcode.org/project/drupal/-/merge_requests/3907#note_172971

I think this will be moved vs added boilerplate in the long run so better to just implement the method now.

(@catch in #39 📌 Update to Symfony 6.3 Fixed )

I think this needs to be done before we're ready for an RTBC, or am I reading this wrong and can this be done in a follow-up?

I opened 📌 Deprecate ::supportedInterfaceOrClass property on normalizer/denormalizers Fixed for that.

Thanks @catch, updated CR to the latest state of the patch.

I think this is now truly RTBC.

+1 rtbc! All followups exist and beta3 happened

@Spokje I did switch to patch because there was broken UI to queue tests for MR for a few days.

@Spokje I did switch to patch because there was broken UI to queue tests for MR for a few days.

Thanks for clearing that up @andypost, I knew "something" was wrong, since you're normally not the one to switch between patches and MRs. :)

I RTBCed this but there's been +1s since then so I think I'm OK to commit it.

Committed/pushed to 11.x and cherry-picked to 10.1.x, thanks!

CR could be published! Thank you!

I published the CR.

RC1 is out https://github.com/symfony/symfony/releases/tag/v6.3.0-RC1

Filed 📌 Update to Symfony 6.3 RC1 Fixed

Automatically closed - issue fixed for 2 weeks with no activity.