Merge branch '7.4' into 8.0

* 7.4:
  Use oskarstark/doctor-rst:1.70.2

Author: OskarStark

.github/workflows/ci.yaml

@@ -72,7 +72,7 @@ jobs:
                     key: ${{ runner.os }}-doctor-rst-${{ steps.extract_base_branch.outputs.branch }}
 
             -   name: "Run DOCtor-RST"
-                uses: docker://oskarstark/doctor-rst:1.70.1
+                uses: docker://oskarstark/doctor-rst:1.70.2
                 with:
                     args: --short --error-format=github --cache-file=/github/workspace/.cache/doctor-rst.cache
 

mailer.rst

@@ -1745,7 +1745,7 @@ SentMessageEvent
 
 **Event Class**: :class:`Symfony\\Component\\Mailer\\Event\\SentMessageEvent`
 
-``SentMessageEvent`` allows you to act on the :class:`Symfony\\Component\\\Mailer\\\SentMessage`
+``SentMessageEvent`` allows you to act on the :class:`Symfony\\Component\\Mailer\\SentMessage`
 class to access the original message (``getOriginalMessage()``) and some
 :ref:`debugging information <mailer-debugging-emails>` (``getDebug()``) such as
 the HTTP calls made by the HTTP transports, which is useful for debugging errors::

scheduler.rst

@@ -566,22 +566,22 @@ schedule and consider all changes in real-time.
 Strategies for Adding, Removing, and Modifying Entries within the Schedule
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The schedule provides you with the ability to :method:`Symfony\\Component\\Scheduler\Schedule::add`,
-:method:`Symfony\\Component\\Scheduler\Schedule::remove`, or :method:`Symfony\\Component\\Scheduler\Schedule::clear`
+The schedule provides you with the ability to :method:`Symfony\\Component\\Scheduler\\Schedule::add`,
+:method:`Symfony\\Component\\Scheduler\\Schedule::remove`, or :method:`Symfony\\Component\\Scheduler\\Schedule::clear`
 all associated recurring messages, resulting in the reset and recalculation of
 the in-memory stack of recurring messages.
 
 For instance, for various reasons, if there's no need to generate a report, a
 callback can be employed to conditionally skip generating of some or all reports.
 
 However, if the intention is to completely remove a recurring message and its recurrence,
-the :class:`Symfony\\Component\\Scheduler\Schedule` offers a :method:`Symfony\\Component\\Scheduler\Schedule::remove`
-or a :method:`Symfony\\Component\\Scheduler\Schedule::removeById` method. This can
+the :class:`Symfony\\Component\\Scheduler\\Schedule` offers a :method:`Symfony\\Component\\Scheduler\\Schedule::remove`
+or a :method:`Symfony\\Component\\Scheduler\\Schedule::removeById` method. This can
 be particularly useful in your case, especially if you need to halt the generation
 of the recurring message, which involves deleting old reports.
 
 In your handler, you can check a condition and, if affirmative, access the
-:class:`Symfony\\Component\\Scheduler\Schedule` and invoke this method::
+:class:`Symfony\\Component\\Scheduler\\Schedule` and invoke this method::
 
     // src/Scheduler/SaleTaskProvider.php
     namespace App\Scheduler;

security.rst

@@ -637,7 +637,7 @@ Form Login
 
 Most websites have a login form where users authenticate using an
 identifier (e.g. email address or username) and a password. This
-functionality is provided by the built-in :class:`Symfony\\Component\\Security\\Http\Authenticator\\FormLoginAuthenticator`.
+functionality is provided by the built-in :class:`Symfony\\Component\\Security\\Http\\Authenticator\\FormLoginAuthenticator`.
 
 You can run the following command to create everything needed to add a login
 form in your application:

security/voters.rst

@@ -454,7 +454,7 @@ Custom Access Decision Strategy
 
 If none of the built-in strategies fits your use case, define the ``strategy_service``
 option to use a custom service (your service must implement the
-:class:`Symfony\\Component\\Security\\Core\Authorization\\Strategy\\AccessDecisionStrategyInterface`):
+:class:`Symfony\\Component\\Security\\Core\\Authorization\\Strategy\\AccessDecisionStrategyInterface`):
 
 .. configuration-block::