Merge branch '5.1'

* 5.1:
  Add information about resolver argument priority
  Removed a paragrpah in favor of the table of data
  [PHPUnit Bridge] Fix text and table inconsistency
  Update forms.rst

Author: javiereguiluz

components/phpunit_bridge.rst

@@ -836,8 +836,6 @@ its ``bin/simple-phpunit`` command. It has the following features:
 
 * Works with a standalone vendor directory that doesn't conflict with yours;
 * Does not embed ``prophecy`` to prevent any conflicts with its dependencies;
-* Uses PHPUnit 4.8 when run with PHP <=5.5, PHPUnit 5.7 when run with PHP >=5.6
-  and PHPUnit 6.5 when run with PHP >=7.2;
 * Collects and replays skipped tests when the ``SYMFONY_PHPUNIT_SKIPPED_TESTS``
   env var is defined: the env var should specify a file name that will be used for
   storing skipped tests on a first run, and replay them on the second run;

controller/argument_value_resolver.rst

@@ -233,12 +233,12 @@ and adding a priority.
         ;
 
 While adding a priority is optional, it's recommended to add one to make sure
-the expected value is injected. The ``RequestAttributeValueResolver`` has a
-priority of 100. As this one is responsible for fetching attributes from the
-``Request``, it's recommended to trigger your custom value resolver with a
-lower priority. This makes sure the argument resolvers are not triggered when
-the attribute is present. For instance, when passing the user along a
-sub-requests.
+the expected value is injected. The built-in ``RequestAttributeValueResolver``,
+which fetches attributes from the ``Request``, has a priority of ``100``. If your
+resolver also fetches ``Request`` attributes, set a priority of ``100`` or more.
+Otherwise, set a priority lower than ``100`` to make sure the argument resolver
+is not triggered when the ``Request`` attribute is present (for example, when
+passing the user along sub-requests).
 
 .. tip::
 

forms.rst

@@ -459,9 +459,12 @@ Before using validation, add support for it in your application:
 
     $ composer require symfony/validator
 
-Validation is done by adding a set of rules (called constraints) to a class. To
-see this in action, add validation constraints so that the ``task`` field cannot
-be empty and the ``dueDate`` field cannot be empty and must be a valid \DateTime
+Validation is done by adding a set of rules, called (validation) constraints,
+to a class. You can add them either to the entity class or to the form class.
+
+To see the first approach - adding constraints to the entity - in action,
+add the validation constraints, so that the ``task`` field cannot be empty,
+and the ``dueDate`` field cannot be empty, and must be a valid ``DateTime``
 object.
 
 .. configuration-block::
@@ -544,9 +547,11 @@ object.
         }
 
 That's it! If you re-submit the form with invalid data, you'll see the
-corresponding errors printed out with the form. Read the
-:doc:`Symfony validation documentation </validation>` to learn more about this
-powerful feature.
+corresponding errors printed out with the form.
+
+To see the second approach - adding constraints to the form - and to
+learn more about the validation constraints, please refer to the
+:doc:`Symfony validation documentation </validation>`.
 
 Other Common Form Features
 --------------------------