Merge branch '5.4' into 6.0

javiereguiluz · javiereguiluz · commit d51cad171581 · 2023-01-24T12:29:36.000+01:00
* 5.4:
  Fix some code issue
  [Refs] Fixed refs displaying incorrectly
diff --git a/.doctor-rst.yaml b/.doctor-rst.yaml
@@ -94,6 +94,7 @@ whitelist:
         - 'provides a ``loginUser()`` method to simulate logging in in your functional'
         - '.. code-block:: twig'
         - '.. versionadded:: 3.6' # MonologBundle
+        - '.. versionadded:: 3.8' # MonologBundle
         - '// bin/console'
         - '.. _`a feature to test applications using Mercure`: https://github.com/symfony/panther#creating-isolated-browsers-to-test-apps-using-mercure-or-websocket'
         - '..  End to End Tests (E2E)'
diff --git a/components/lock.rst b/components/lock.rst
@@ -299,7 +299,7 @@ will fallback to a write lock by calling the ``acquire()`` method.
 The Owner of The Lock
 ---------------------
 
-Locks that are acquired for the first time are owned [1]_ by the ``Lock`` instance that acquired
+Locks that are acquired for the first time are :ref:`owned <lock-owner-technical-details>` by the ``Lock`` instance that acquired
 it. If you need to check whether the current ``Lock`` instance is (still) the owner of
 a lock, you can use the ``isAcquired()`` method::
 
@@ -336,7 +336,11 @@ lose the lock it acquired automatically::
     you have to use ``acquire()`` for this. The ``isAcquired()`` method is used to check
     if the lock has been acquired by the **current process** only.
 
-.. [1] Technically, the true owners of the lock are the ones that share the same instance of ``Key``,
+.. _lock-owner-technical-details:
+
+.. note::
+
+    Technically, the true owners of the lock are the ones that share the same instance of ``Key``,
     not ``Lock``. But from a user perspective, ``Key`` is internal and you will likely only be working
     with the ``Lock`` instance so it's easier to think of the ``Lock`` instance as being the one that
     is the owner of the lock.
diff --git a/contributing/code/core_team.rst b/contributing/code/core_team.rst
@@ -146,7 +146,7 @@ Pull Request Merging Policy
 
 A pull request **can be merged** if:
 
-* It is a minor change [1]_;
+* It is a :ref:`minor change <core-team_minor-changes>`;
 
 * Enough time was given for peer reviews;
 
@@ -162,7 +162,8 @@ Pull Request Merging Process
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 All code must be committed to the repository through pull requests, except for
-minor changes [1]_ which can be committed directly to the repository.
+:ref:`minor change <core-team_minor-changes>` which can be committed directly
+to the repository.
 
 **Mergers** must always use the command-line ``gh`` tool provided by the
 **Project Leader** to merge the pull requests.
@@ -178,8 +179,12 @@ Symfony Core Rules and Protocol Amendments
 The rules described in this document may be amended at any time at the
 discretion of the **Project Leader**.
 
-.. [1] Minor changes comprise typos, DocBlock fixes, code standards
-       violations, and minor CSS, JavaScript and HTML modifications.
+.. _core-team_minor-changes:
+
+.. note::
+
+    Minor changes comprise typos, DocBlock fixes, code standards
+    violations, and minor CSS, JavaScript and HTML modifications.
 
 .. _`symfony-docs repository`: https://github.com/symfony/symfony-docs
 .. _`fabpot`: https://github.com/fabpot/
