Merge remote-tracking branch 'upstream/6.0' into 6.0

* upstream/6.0:
  Some minor rewords
  Fixed XML syntax too
  Typo in class name
  Fix example in Regex.rst
  Global variable in TwigConfig should be passed by service function
  Fixed ambiguous sentence
  [Contribution] Document the different types of tests run in CI
  Added header removal notice
  Minor clarification
  Minor change at email_validation_mode

Author: OskarStark

contributing/code/pull_requests.rst

@@ -429,6 +429,68 @@ After the `Psalm phar is installed`_, the analysis can be run locally with:
 
     $ psalm.phar src/Symfony/Component/Workflow
 
+Automated Tests
+~~~~~~~~~~~~~~~
+
+A series of automated tests will run when submitting the pull request.
+These test the code under different conditions, to be sure nothing
+important is broken. Test failures can be unrelated to your changes. If you
+think this is the case, you can check if the target branch has the same
+errors and leave a comment on your PR.
+
+Otherwise, the test failure might be caused by your changes. The following
+test scenarios run on each change:
+
+``PHPUnit / Tests``
+    This job runs on Ubuntu using multiple PHP versions (each in their
+    own job). These jobs run the testsuite just like you would do locally.
+
+    A failure in these jobs often indicates a bug in the code.
+
+``PHPUnit / Tests (high-deps)``
+    This job checks each package (bridge, bundle or component) in ``src/``
+    individually by calling ``composer update`` and ``phpunit`` from inside
+    each package.
+
+    A failure in this job often indicates a missing package in the
+    ``composer.json`` of the failing package (e.g.
+    ``src/Symfony/Bundle/FrameworkBundle/composer.json``).
+
+    This job also runs relevant packages using a "flipped" test (indicated
+    by a ``^`` suffix in the package name). These tests checkout the
+    previous major release (e.g. ``4.4`` for a pull requests on ``5.4``)
+    and run the tests with your branch as dependency.
+
+    A failure in these flipped tests indicate a backwards compatibility
+    break in your changes.
+
+``PHPUnit / Tests (low-deps)``
+    This job also checks each package individually, but then uses
+    ``composer update --prefer-lowest`` before running the tests.
+
+    A failure in this job often indicates a wrong version range or a
+    missing package in the ``composer.json`` of the failing package.
+
+``continuous-integration/appveyor/pr``
+    This job runs on Windows using the x86 architecture and the lowest
+    supported PHP version. All tests first run without extra PHP
+    extensions. Then, all skipped tests are run using all required PHP
+    extensions.
+
+    A failure in this job often indicate that your changes do not support
+    Windows, x86 or PHP with minimal extensions.
+
+``Integration / Tests``
+    Integration tests require other services (e.g. Redis or RabbitMQ) to
+    run. This job only runs the tests in the ``integration`` PHPUnit group.
+
+    A failure in this job indicates a bug in the communication with these
+    services.
+
+``PHPUnit / Tests (experimental)``
+    This job always passes (even with failing tests) and is used by the
+    core team to prepare for the upcoming PHP versions.
+
 .. _rework-your-patch:
 
 Rework your Pull Request

frontend/encore/babel.rst

@@ -24,7 +24,7 @@ Need to extend the Babel configuration further? The easiest way is via
             babelConfig.plugins.push('styled-jsx/babel');
         }, {
             // node_modules is not processed through Babel by default
-            // but you can whitelist specific modules to process
+            // but you can allow some specific modules to be processed
             includeNodeModules: ['foundation-sites'],
 
             // or completely control the exclude rule (note that you

mailer.rst

@@ -1101,13 +1101,14 @@ This can be configured by replacing the ``dsn`` configuration entry with a
             ;
         };
 
-By default the first transport is used. The other transports can be used by
-adding a text header ``X-Transport`` to an email::
+By default the first transport is used. The other transports can be selected by
+adding an ``X-Transport`` header (which Mailer will remove automatically from
+the final email)::
 
-    // Send using first "main" transport ...
+    // Send using first transport ("main"):
     $mailer->send($email);
 
-    // ... or use the "alternative" one
+    // ... or use the transport "alternative":
     $email->getHeaders()->addTextHeader('X-Transport', 'alternative');
     $mailer->send($email);
 

reference/configuration/framework.rst

@@ -607,7 +607,7 @@ instance), the host might have been manipulated by an attacker.
 The Symfony :method:`Request::getHost() <Symfony\\Component\\HttpFoundation\\Request::getHost>`
 method might be vulnerable to some of these attacks because it depends on
 the configuration of your web server. One simple solution to avoid these
-attacks is to whitelist the hosts that your Symfony application can respond
+attacks is to configure a list of hosts that your Symfony application can respond
 to. That's the purpose of this ``trusted_hosts`` option. If the incoming
 request's hostname doesn't match one of the regular expressions in this list,
 the application won't respond and the user will receive a 400 response.
@@ -2708,7 +2708,7 @@ email_validation_mode
 
 **type**: ``string`` **default**: ``loose``
 
-It controls the way email addresses are validated by the
+Sets the default value for 
 :doc:`/reference/constraints/Email` validator. The possible values are:
 
 * ``loose``, it uses a simple regular expression to validate the address (it

reference/constraints/Regex.rst

@@ -244,7 +244,7 @@ need to specify the HTML5 compatible pattern in the ``htmlPattern`` option:
         {
             #[Assert\Regex(
                 pattern: '/^[a-z]+$/i',
-                match: '^[a-zA-Z]+$'
+                htmlPattern: '^[a-zA-Z]+$'
             )]
             protected $name;
         }

reference/constraints/Uuid.rst

@@ -4,7 +4,7 @@ UUID
 Validates that a value is a valid `Universally unique identifier (UUID)`_ per `RFC 4122`_.
 By default, this will validate the format according to the RFC's guidelines, but this can
 be relaxed to accept non-standard UUIDs that other systems (like PostgreSQL) accept.
-UUID versions can also be restricted using a whitelist.
+UUID versions can also be restricted using a list of allowed versions.
 
 ==========  ===================================================================
 Applies to  :ref:`property or method <validation-property-target>`

security.rst

@@ -1076,8 +1076,8 @@ like this:
   will have ``IS_AUTHENTICATED_REMEMBERED`` but will not have ``IS_AUTHENTICATED_FULLY``.
 
 * ``IS_AUTHENTICATED_ANONYMOUSLY``: *All* users (even anonymous ones) have
-  this - this is useful when *whitelisting* URLs to guarantee access - some
-  details are in :doc:`/security/access_control`.
+  this - this is useful when defining a list of URLs with no access restriction
+  - some details are in :doc:`/security/access_control`.
 
 * ``IS_ANONYMOUS``: *Only* anonymous users are matched by this attribute.
 

service_container/factories.rst

@@ -204,7 +204,7 @@ method name:
 
             App\Email\NewsletterManager:
                 class:   App\Email\NewsletterManager
-                factory: '@App\Email\NewsletterManagerFactory'
+                factory: '@App\Email\InvokableNewsletterManagerFactory'
 
     .. code-block:: xml
 
@@ -220,7 +220,7 @@ method name:
 
                 <service id="App\Email\NewsletterManager"
                          class="App\Email\NewsletterManager">
-                    <factory service="App\Email\NewsletterManagerFactory"/>
+                    <factory service="App\Email\InvokableNewsletterManagerFactory"/>
                 </service>
             </services>
         </container>
@@ -237,7 +237,7 @@ method name:
             $services = $configurator->services();
 
             $services->set(NewsletterManager::class)
-                ->factory(service(NewsletterManagerFactory::class));
+                ->factory(service(InvokableNewsletterManagerFactory::class));
         };
 
 .. _factories-passing-arguments-factory-method:

setup/upgrade_minor.rst

@@ -41,7 +41,7 @@ probably need to update the version constraint next to each library starting
               "...": "...",
 
               "...": "A few libraries starting with
-                      symfony/ follow their versioning scheme. You
+                      symfony/ follow their own versioning scheme. You
                       do not need to update these versions: you can
                       upgrade them independently whenever you want",
               "symfony/monolog-bundle": "^3.5",

templating/global_variables.rst

@@ -92,19 +92,20 @@ the ``@`` character, which is the usual syntax to
 
             <twig:config>
                 <!-- ... -->
-                <twig:global key="uuid">@App\Generator\UuidGenerator</twig:global>
+                <twig:global key="foo" id="App\Generator\UuidGenerator" type="service"/>
             </twig:config>
         </container>
 
     .. code-block:: php
 
         // config/packages/twig.php
         use Symfony\Config\TwigConfig;
+        use function Symfony\Component\DependencyInjection\Loader\Configurator\service;
 
         return static function (TwigConfig $twig) {
             // ...
 
-            $twig->global('uuid')->value('@App\Generator\UuidGenerator');
+            $twig->global('uuid')->value(service('App\Generator\UuidGenerator'));
         };
 
 Now you can use the ``uuid`` variable in any Twig template to access to the