Update to Symfony 6.3

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

Adding the deprecation skip from #3351556-8: Update dependencies for Drupal 10.1/Add deprecation silencer on Drupal 10.0 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:

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.

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 (counterproductive) 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?

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

The Symfony PR about this can be found here: https://github.com/symfony/symfony/pull/49291

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 #3022583: [META] Normalization System: clean up/speed up/provide schema. Then Symfony shipped CacheableSupportsMethodInterface which was a step in the right direction — see #3031214-19: Introduce "deterministic" normalizers and #3252872: Use CacheableSupportsMethodInterface for performance improvement in 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

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 #3360103: Missing test coverage for some validators

A reroll was needed due to #3358323: Update dependencies for Drupal 10.1. 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 #3360124: Deprecate ::supportedInterfaceOrClass property on normalizer/denormalizers 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.

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 #3360152: Consider disabling the Drupal.Commenting.FunctionComment.VoidReturn rule 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)

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 #3360124: Deprecate ::supportedInterfaceOrClass property on normalizer/denormalizers 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 #3361949: Update to Symfony 6.3 RC1