Allow Symfony 4.4 to be installed in Drupal 8

The reason the testbot isn't picking up changes is because the patch is only to composer.json - composer.lock is also in version control, so needs to be updated too here, then it should explode as expected.

Also, thanks for picking this up!

It would be great if we can try the combined patch from #2948700: Casting $text value to string in responseContains/responseNotContains methods and this issue.

Let's create another combine patch with the utf8 issue also upload the review the only patch which I assume is uploaded in #18.

It would be appropriate to signal to contrib that the arguments of the DrupalKernel constructor are deprecated/scheduled for change in D9...

It's fine to deprecate constructor arguments and trigger the deprecation in a minor, and a change record is enough. It doesn't matter if the constructor changes again in another minor.

1) A refactoring of routing, a better understanding based on simultaneous parsing of a single mega regular expression

We don't actually use Symfony's routing logic at all at this point, just some interfaces and the Route class.

This was done to be scalable with large number of routes (i.e. the problem they claim to have solved). So any comparison would have to be between our database-based router and the new version of Symfony's router - i.e. it will require a separate issue to undo our customisations and then test.

Some of the fails in the last patch have been fixed in #2992113: Update core dependencies before 8.6.2

What about rewrite \Drupal\Core\DrupalKernel::initializeSettings() which using deprecated \Symfony\Component\ClassLoader\ApcClassLoader ref https://symfony.com/doc/3.3/components/class_loader/cache_class_loader.html

It means whole symfony/class-loader dependency must be removed

Looks related issue could be fixed in minor release but not sure about removal of dependency

See also #2917331: Decouple from Symfony CMF

Nice. Remaining fails are variations on this:

1) Drupal\Tests\file\Functional\Hal\FileUploadHalJsonCookieTest::testPostFileUploadInvalidHeaders
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'{"message":"\u0022Content-Disposition\u0022 header is required. A file name in the format \u0022filename=FILENAME\u0022 must be provided"}'
+'{"message":"No filename found in \u0022Content-Disposition\u0022 header. A file name in the format \u0022filename=FILENAME\u0022 must be provided"}'

/var/www/html/core/modules/rest/tests/src/Functional/ResourceTestBase.php:393
/var/www/html/core/modules/rest/tests/src/Functional/ResourceTestBase.php:455
/var/www/html/core/modules/rest/tests/src/Functional/FileUploadResourceTestBase.php:258

If we can make the assertion a bit more agnostic that might be enough?

#48 - #3001542: Update Guzzle from 6.3.0 to 6.3.3

Looks only classloader & #48 tests are need fix now

#48: interesting failure! I agree with If we can make the assertion a bit more agnostic that might be enough?.

… at least I agreed based on the assumption that a Symfony change caused the exception message to change. But both exceptions (and their messages) are thrown by Drupal code (\Drupal\file\Plugin\rest\resource\FileUploadResource::validateAndParseContentDispositionHeader()). Which means that Symfony changed something.

This is the relevant code:

  protected function validateAndParseContentDispositionHeader(Request $request) {
    // Firstly, check the header exists.
    if (!$request->headers->has('content-disposition')) {
      throw new BadRequestHttpException('"Content-Disposition" header is required. A file name in the format "filename=FILENAME" must be provided');
    }

    $content_disposition = $request->headers->get('content-disposition');

    // Parse the header value. This regex does not allow an empty filename.
    // i.e. 'filename=""'. This also matches on a word boundary so other keys
    // like 'not_a_filename' don't work.
    if (!preg_match(static::REQUEST_HEADER_FILENAME_REGEX, $content_disposition, $matches)) {
      throw new BadRequestHttpException('No filename found in "Content-Disposition" header. A file name in the format "filename=FILENAME" must be provided');
    }

…

So the test failures are occurring because a request with Foo: had $request->headers->has('foo') return FALSE in Symfony 3 but TRUE in Symfony 4.

From 8 to 4 failures. #57 worked :) The remaining 4 failures are in the class loader, composer integration and kernel.

So the test failures are occurring because a request with Foo: had $request->headers->has('foo') return FALSE in Symfony 3 but TRUE in Symfony 4.

Both versions mostly identical, the only change in SF not related to has() implementation

The DrupalKernel test failure is testing for the apcu classloader which we no longer attempt to register, so we probably just need to remove that test entirely.

Also

1) Drupal\Tests\ComposerIntegrationTest::testMinPHPVersion
doctrine/cache has a PHP dependency requirement of "~7.1"
Failed asserting that false is true.

/var/www/html/core/tests/Drupal/Tests/ComposerIntegrationTest.php:208

For the purposes of this we need to bump our PHP requirements to 7.1, another option would be to remove that test.

Theoretically gets us down to two fails. Also had to re-roll a composer.json change.

Re #57 we already had to deal with a similar issue in #2992113-17: Update core dependencies before 8.6.2.

Actual PHP requirement needs to be 7.1.3 not 7.1.

Aha, my bad! It's introduced by Guzzle 6.3.0 -> 6.3.3 then.

+++ b/core/lib/Drupal/Core/DrupalKernel.php
@@ -1067,40 +1067,6 @@ protected function initializeSettings(Request $request) {
-
-    // If the class loader is still the same, possibly
-    // upgrade to an optimized class loader.
-    if ($class_loader_class == get_class($this->classLoader)
-        && Settings::get('class_loader_auto_detect', TRUE)) {
-      $prefix = Settings::getApcuPrefix('class_loader', $this->root);
-      $loader = NULL;
-
-      // We autodetect one of the following three optimized classloaders, if
-      // their underlying extension exists.
-      if (function_exists('apcu_fetch')) {
-        $loader = new ApcClassLoader($prefix, $this->classLoader);
-      }

Do we need to test the impact of this somehow? Or find an alternative?

I imagine a lot of users aren't going to be using --optimize-classloader. At the same time, wondering if it might actually be faster without this for those that *do*, or did we already skip it then, not sure I fully understand the check here righ tnow.

One thing though, if we remove this, we can also remove "$class_loader_class = get_class($this->classLoader);" a few lines above.

@Berdir: "Do we need to test the impact of this somehow? Or find an alternative?"

+++ b/composer.json
@@ -13,6 +13,7 @@
+        "apcu-autoloader": true,

The patch currently does this, but yeah we need to see what's going on and might have to make our own apcu classloader if this is no good.

Nothing stops us adding our own apcu classloader to 8.x if we need to.

This is what's left and a real problem:

1) Drupal\Tests\system\Functional\Module\ClassLoaderTest::testClassLoadingNotInstalledModules
"Drupal\module_autoload_test\SomeClass::testMethod() was invoked." not found
Failed asserting that false is true.

/var/www/html/core/tests/Drupal/KernelTests/AssertLegacyTrait.php:31
/var/www/html/core/tests/Drupal/FunctionalTests/AssertLegacyTrait.php:140
/var/www/html/core/tests/Drupal/FunctionalTests/AssertLegacyTrait.php:111
/var/www/html/core/modules/system/tests/src/Functional/Module/ClassLoaderTest.php:56

2) Drupal\Tests\system\Functional\Module\ClassLoaderTest::testClassLoadingDisabledModules
"Drupal\module_autoload_test\SomeClass::testMethod() was invoked." not found
Failed asserting that false is true.

/var/www/html/core/tests/Drupal/KernelTests/AssertLegacyTrait.php:31
/var/www/html/core/tests/Drupal/FunctionalTests/AssertLegacyTrait.php:140
/var/www/html/core/tests/Drupal/FunctionalTests/AssertLegacyTrait.php:111
/var/www/html/core/modules/system/tests/src/Functional/Module/ClassLoaderTest.php:76

@catch does it mean that 8.x should use some shim/bridge to current classloader interface while 9.x should be composer-based #1818628: Use Composer's optimized ClassLoader for Core/Component classes where in #95 I filed that apcu is not the best now

Probably better to deprecate class_loader_auto_detect settings?

@andypost not sure yet, we should open an issue to discuss this separately from this one, but just a note #2704571: Add an APCu classloader with a single entry has been open for two years and needs reviews.

I'm unable to reproduce the fail in #70 locally, would be useful if someone else could try running that with the latest patch.

+++ b/core/modules/file/src/Plugin/rest/resource/FileUploadResource.php
@@ -349,7 +349,7 @@ protected function streamUploadData() {
-    if (!$request->headers->has('content-disposition')) {
+    if (!$request->headers->has('content-disposition') || empty($request->headers->get('content-disposition'))) {
       throw new BadRequestHttpException('"Content-Disposition" header is required. A file name in the format "filename=FILENAME" must be provided');
     }

This change looks like something which could be a problem in more spaces, we just don't have the needed test coverage.

If we are bumping PHP version here then #2992116: Bump core dependencies minimum version to PHP 7.0 is a duplicate.

@martin107: there is not even a branch yet for Symfony 5 at https://github.com/symfony/symfony! As per the same blog post, let's focus on supporting Symfony 4 as a stepping stone to Symfony 5, so we don't need to do all the work at closer to the finish line and frontload some effort as much as we can. The Symfony 5 issue is at #3009255: [META] Symfony 5.0 compatibility by the way.

For now I re-rolled over at #3020303: Consider using Symfony flex to allow switching between major Symfony versions and discovered new test failures due to newly introduced deprecations in Symfony 4.2.

Cross-post - and agreed with Gabor. Symfony 5 will probably branch around the same time as Symfony 4.4 does, until then we need to track Symfony 4 minor updates which we may also have to adapt for.

OK there are multiple new issues introduced with Symfony 4.2, so moving back here to flush them out, but will keep opening sub-issues.

Current state of the patch:

1. Keeps symfony-classloader pinned at 3.4, that's all we need to do to enable Symfony 4, although we'll need to replace it in time for 9.x in #3020296: Remove Symfony's classloader as it does not exist in Symfony 4

2. Incorporates the patch from #3020385: Symfony 3 and Symfony ^4.2 JsonEncode constructors are incompatible.

3. Incorporates #3020301: Remove composer integration PHP version test (rely on DrupalCI PHP version runs instead).

I'm adding these as children under #2937984: [META] Symfony 4.0 compatibility.

New combi patch - I'm splitting out sub-issues as I go, so see the child issues of #2937984: [META] Symfony 4.0 compatibility for specifics.

And with #3020550: Passing commands as a string to Process is deprecated in Symfony 4.

Incorporating #3020579: TypeError: Argument 3 passed to Symfony\Component\HttpKernel\Event\FilterResponseEvent::__construct() must be of the type integer, string given [Symfony 4]

Are planning to commit this patch to D8 at some point? Can we please make the expectation clear in IS? Because as it stands composer install is failing on PHP 7.0 which means we can't commit this patch to Drupal 8.8 unless we fix it.

Only the spin-off issues should be committed, this issue is mostly for testing. I updated the issue summary.

Re-rolled.

Doctrine needs to be at 2.10.

Now including #3021236: Page cache test fails with Symfony 3.4.19 and above.

This now just contains the composer changes and #3020301: Remove composer integration PHP version test (rely on DrupalCI PHP version runs instead).

Re-rolled. Will still fail with one test failure until #3020301: Remove composer integration PHP version test (rely on DrupalCI PHP version runs instead) lands.

I committed #3020301: Remove composer integration PHP version test (rely on DrupalCI PHP version runs instead) and queued a retest.

Doesn't look like every component got updated to 4.x for the test run. E.g.,

+++ b/composer.lock
@@ -2331,20 +2692,20 @@
             "name": "symfony/validator",
-            "version": "v3.4.15",
+            "version": "v3.4.21",

And others.

A few components are still specifying <4.0.0 so we need to update those too. Good spot. New patch.

Cruft.

And including #2961861: Remove usage of WriteCheckSessionHandler.

Looking at various fails, this pattern is repeating:

Drupal\Tests\field\Functional\Hal\FieldConfigHalJsonCookieTest::testGet
Exception: TypeError: Argument 1 passed to Symfony\Component\HttpFoundation\Response::setCharset() must be of the type string, null given, called in /var/www/html/core/modules/rest/src/EventSubscriber/ResourceResponseSubscriber.php on line 210
Symfony\Component\HttpFoundation\Response->setCharset()() (Line: 496)

Drupal\Tests\action\Functional\ActionListTest::testEmptyActionList
Exception: TypeError: Argument 1 passed to Symfony\Component\HttpFoundation\Response::setCharset() must be of the type string, null given, called in /var/www/html/core/lib/Drupal/Component/HttpFoundation/SecuredRedirectResponse.php on line 43
Symfony\Component\HttpFoundation\Response->setCharset()() (Line: 496)

There are also other fails, some of which look like could be side effects of this (ie. when a webtest checks site output and the page fails with the exception).

Opened #3027835: [symfony 4] Argument 1 passed to Symfony\Component\HttpFoundation\Response::setCharset() must be of the type string, null given with a patch.

That uncovered two more issues:

#3027871: [symfony 5] Symfony\Component\Validator\Constraints\Email::$strict property is deprecated since Symfony 4.1

and

#3027872: [symfony 4] The default value of the "$secure" and "$samesite" arguments of "Symfony\Component\HttpFoundation\Cookie::__construct"'s constructor will change

Those two "only" result in a total of 269 fails.

Uploading the combine patch with #3027871: [symfony 5] Symfony\Component\Validator\Constraints\Email::$strict property is deprecated since Symfony 4.1

Should we upgrade these libraries as well?

diff --git a/core/composer.json b/core/composer.json
index 9252ba4d6a..6f8a836b80 100644
--- a/core/composer.json
+++ b/core/composer.json
@@ -61,9 +61,9 @@
         "mikey179/vfsStream": "^1.2",
         "phpunit/phpunit": "^4.8.35 || ^6.5",
         "phpspec/prophecy": "^1.7",
-        "symfony/css-selector": "^3.4.0",
-        "symfony/phpunit-bridge": "^3.4.3",
-        "symfony/debug": "^3.4.0"
+        "symfony/css-selector": "^3.4.0|~4.0",
+        "symfony/phpunit-bridge": "^3.4.3|~4.0",
+        "symfony/debug": "^3.4.0|~4.0"

There's a lot of errors like

2) Drupal\Tests\aggregator\Functional\AddFeedTest::testFeedLabelEscaping
"The feed Test feed title <script>alert(123);</script> has been added." found
Failed asserting that false is true.

No time to spin an issue out right now though, but that seems like it'd clear a lot of the remaining 200 maybe.

@jibran: re #115 I think so yeah. Now that #3027871: [symfony 5] Symfony\Component\Validator\Constraints\Email::$strict property is deprecated since Symfony 4.1 landed, this will need a reroll. That in itself will not raise new issues, but #115 may.

@catch: interesting, most fails are in messages, but I don't see the pattern, so not sure what to open an issue about. This message fail from a JS test may help find the reason:

1) Drupal\Tests\block_content\Functional\Hal\BlockContentHalJsonAnonTest::testPost
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'{"message":"Unprocessable Entity: validation failed.\ninfo: Block description: this field cannot hold more than 1 values.\n"}'
+'{"message":"Unprocessable Entity: validation failed.\nstatus.0: The value you selected is not a valid choice.\ninfo: Block description: this field cannot hold more than 1 values.\nreusable.0: The value you selected is not a valid choice.\ndefault_langcode.0: The value you selected is not a valid choice.\n"}'

Addressed #115.

Opened #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead and #3029199: [symfony 5] Calling "Symfony\Component\HttpFoundation\Request::getSession()" when no session has been set is deprecated since Symfony 4.1 both of which may be relatively easy to fix and are a huge part of the fails.

There's a lot of errors like

2) Drupal\Tests\aggregator\Functional\AddFeedTest::testFeedLabelEscaping
"The feed Test feed title <script>alert(123);</script> has been added." found
Failed asserting that false is true.

No time to spin an issue out right now though, but that seems like it'd clear a lot of the remaining 200 maybe.

given

1) Drupal\Tests\block_content\Functional\Hal\BlockContentHalJsonAnonTest::testPost
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'{"message":"Unprocessable Entity: validation failed.\ninfo: Block description: this field cannot hold more than 1 values.\n"}'
+'{"message":"Unprocessable Entity: validation failed.\nstatus.0: The value you selected is not a valid choice.\ninfo: Block description: this field cannot hold more than 1 values.\nreusable.0: The value you selected is not a valid choice.\ndefault_langcode.0: The value you selected is not a valid choice.\n"}'

Those look to be related to #2937542: Not setting the strict option of the Choice constraint to true is deprecated since Symfony 3.4 and will throw an exception in 4.0

I'm a bit curious. This patch adds #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead and #3029199: [symfony 5] Calling "Symfony\Component\HttpFoundation\Request::getSession()" when no session has been set is deprecated since Symfony 4.1 to the deprecation ignore list and includes the patch from #2937542: Not setting the strict option of the Choice constraint to true is deprecated since Symfony 3.4 and will throw an exception in 4.0 . I'm curious how much that cleans up.

Yay, thanks, fingers crossed. #3029199: [symfony 5] Calling "Symfony\Component\HttpFoundation\Request::getSession()" when no session has been set is deprecated since Symfony 4.1 is patchable and has a patch RTBC now :) #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead should indeed go on the ignore list, proposed a patch there.

A good chunk of the remaining functional test failures seem to be due to escaping Constraint Violation messages. The test is looking for A feed named <em class="placeholder">iD5qjReymv</em> already exists. Enter a unique title. and the response contains A feed named <em class="placeholder">iD5qjReymv</em> already exists. Enter a unique title.

I'm only starting to dig into why that might be happening, but I thought I would mention it in case it triggered any ideas with anyone who has been working with this more than I have. It's definitly coming through as A feed named <em class="placeholder">iD5qjReymv</em> already exists. Enter a unique title. on the output page without the upgraded dependencies.

#123 is being caused by type coercion. \Symfony\Component\Validator\ConstraintViolation::__construct() causes the TranslatableMarkup object to be casted into a string and therefore Twig no longer considers this as a safe string and will escape the HTML. The only thing we can do here is sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation()... but the Symfony class uses privates... not going to be pretty.

Also, now a big chunk of the fails are our own deprecations :D Opened #3029500: Drupal\Core\Database\Query\Select::hasAllTags() and hasAnyTag() will require a new "$tags" argument in the next major version of its parent class.

This is a combo test with #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead, #3029540: [Symfony 4] Sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation(), and #2937542: Not setting the strict option of the Choice constraint to true is deprecated since Symfony 3.4 and will throw an exception in 4.0

This rolls in #3029500-10: Drupal\Core\Database\Query\Select::hasAllTags() and hasAnyTag() will require a new "$tags" argument in the next major version of its parent class as well.

Re-rolling, and also using the most recent patch from #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead because the alternative approach there is not yet covering all of those deprecations.

Opened #3029697: [Symfony 4] Exception: Notice: A non well formed numeric value encountered.

Opened #3029979: [Symfony 4] ClassFinder test is broken by Symfony's debug classloader.

Opened #3029991: [Symfony 4] Container tests failing due to invalid exception argument type. with a patch.

Rerolled. The only patch that was in this one was #3029500: Drupal\Core\Database\Query\Select::hasAllTags() and hasAnyTag() will require a new "$tags" argument in the next major version of its parent class. Other things that landed since then should improve the passing rate.

> Error: Call to undefined method Symfony\Component\HttpFoundation\Request::setTrustedHeaderName()

https://symfony.com/blog/fixing-the-trusted-proxies-configuration-for-sy...

Looks like they forgot to mark that as deprecated in 3.3?

@berdir: ReverseProxyMiddlewareTest has an @expectedDeprecation for setTrustedHeaderName() so we hid it for ourselves.

I went through all the fails and I think this covers it all:

This combined patch currently contains:

- #3029540: [Symfony 4] Sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation()
- #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead

The fails that it produces are covered by:

- #3029979: [Symfony 4] ClassFinder test is broken by Symfony's debug classloader
- #3030474: Drupal\Core\TypedData\Validation\ExecutionContext uses internal methods from Symfony\Component\Validator\Context\ExecutionContextInterface (new)
- #3030485: [Symfony 5] The "Drupal\Core\Validation\TranslatorInterface" interface extends "Symfony\Component\Translation\TranslatorInterface" that is deprecated since Symfony 4.2, use Symfony\Contracts\Translation\TranslatorInterface instead. (new)
- #3030494: [Twig 3] The "Drupal\Core\Template\Loader\StringLoader" class implements "Twig_ExistsLoaderInterface" and "Twig_SourceContextLoaderInterface" that are deprecated since 1.12 and 1.27 (to be removed in 3.0). (new)
- #3030501: [Symfony 4] Drupal\Core\StackMiddleware\ReverseProxyMiddleware calls Symfony\Component\HttpFoundation\Request::setTrustedHeaderName() which does not exist (new)

I think the combination of those cover ALL the fails we are seeing in #134.

Additionally to the above, the following two Symfony 4 deprecation messages are made to disappear in Drupal\Tests\Listeners\DeprecationListenerTrait:

      'The Symfony\Component\ClassLoader\ApcClassLoader class is deprecated since Symfony 3.3 and will be removed in 4.0. Use `composer install --apcu-autoloader` instead.',
      'The Symfony\Component\ClassLoader\WinCacheClassLoader class is deprecated since Symfony 3.3 and will be removed in 4.0. Use `composer install --apcu-autoloader` instead.',

I also looked at @expectedDeprecation instances in core based on finding out that those were hiding an issue in #3030501. There are these in Drupal\Tests\Component\EventDispatcher\ContainerAwareEventDispatcherTest:

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. U
se EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testAddAListenerService() {
      parent::testAddAListenerService();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. U
se EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testPreventDuplicateListenerService() {
      parent::testPreventDuplicateListenerService();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. Use EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testAddASubscriberService() {
      parent::testAddASubscriberService();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. Use EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testHasListenersOnLazyLoad() {
      parent::testHasListenersOnLazyLoad();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. Use EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testGetListenersOnLazyLoad() {
      parent::testGetListenersOnLazyLoad();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. Use EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testRemoveAfterDispatch() {
      parent::testRemoveAfterDispatch();
    }

    /**
     * @expectedDeprecation The Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher class is deprecated since Symfony 3.3 and will be removed in 4.0. Use EventDispatcher with closure factories instead.
     * @group legacy
     */
    public function testRemoveBeforeDispatch() {
      parent::testRemoveBeforeDispatch();
    }

#3030501: [Symfony 4] Drupal\Core\StackMiddleware\ReverseProxyMiddleware calls Symfony\Component\HttpFoundation\Request::setTrustedHeaderName() which does not exist just landed, yay!

As for the classloader skipped deprecation messages uncovered in #138 I believe #3020296: Remove Symfony's classloader as it does not exist in Symfony 4 will deal with them, but that seems to be possible to do independent of Symfony 4 compatibility as we can independently stick to the old class loader versions at least alongside Symfony 4.

I don't know what to do about the @expectedDeprecation's around ContainerAwareEventDispatcher.

#3030485: [Symfony 5] The "Drupal\Core\Validation\TranslatorInterface" interface extends "Symfony\Component\Translation\TranslatorInterface" that is deprecated since Symfony 4.2, use Symfony\Contracts\Translation\TranslatorInterface instead. and #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead also landed. Working on a reroll now.

The only other patch this contains now is #3029540: [Symfony 4] Sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation() on top of the composer changes. Let's see what is still or newly failing.

No diff other than the removal of #3029197: [symfony 5] Class implements "Symfony\Component\DependencyInjection\ResettableContainerInterface" that is deprecated since Symfony 4.2, use "Symfony\Contracts\Service\ResetInterface" instead since it was already committed.

The fails from #2937542: Not setting the strict option of the Choice constraint to true is deprecated since Symfony 3.4 and will throw an exception in 4.0 are back (it was rolled back in the meantime), will roll a compound patch that has that too.

Rolled with that. Let's see testbot.

@alexpott created #3038062: [Symfony 4] Skip ReverseProxyMiddlewareTest::testReverseProxyEnabledLegacy test to properly skip testing \Symfony\Component\HttpFoundation\Request::setTrustedHeaderName() when it does not exist. Running a compound test there to see how it helps.

Ok now both #2937542: Not setting the strict option of the Choice constraint to true is deprecated since Symfony 3.4 and will throw an exception in 4.0 and #3038062: [Symfony 4] Skip ReverseProxyMiddlewareTest::testReverseProxyEnabledLegacy test landed, so we can test purely with the Symfony 4 update again. Just the update in this patch, no fixes.

Whoops, #3029540: [Symfony 4] Sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation() is still needed to cut down the fails to the ones we don't have or cannot do patches for ATM.

This updates Symfony 4.2.2 to 4.2.4, which should fix at least one of the 10 remaining failures.

Let's try that one more time...

Alright then... I thought I screwed up the update, but that wasn't me.. We require symfony/psr-http-message-bridge: ^1.0 which is now 1.2, which deprecates a core service class....

Last attempt tonight, putting psr-http-message-bridge back down to 1.1.1 for now. 1.2 requires php 7.1, so we aren't ready for that just yet.

Well, all that work, and we traded one fixed test for one new fail, lol.

I found an issue for the eventDispatcher issue #2895487: [Symfony 4] ContainerAwareEventDispatcherTest depends on Symfony tests, and tagged it.