[clang-format][docs] Add ability to link to specific config options

[rymiel]

Summary

This allows for the creation of permalinks to specific clang-format
options, for better sharing of a specific option and its options.

(I'm adding the usual clang-format reviewers on this patch because
I don't know any other reviewers that well, perhaps someone with
docs experience should be added instead...)

Note that I wanted to make minimal changes to make this happen and thus
landed on an unideal setup, but to me, it seems like the best out of
worse ones.

I could have made every style option a subheading, which would add
automatically the logic for permalinks and the little paragraph icon for
sharing.

However, this meant that the links themselves would be suboptimal, as
they'd include the whole text of the heading, including the type and
versionbadge, which is needless noise and could change, breaking the
concept of a "permalink". The format of the page could be changed to
put the option names on their own in a heading, and the other info below
it in a paragraph.

As Sphinx seems unwilling to fix https://github.com/sphinx-doc/sphinx/issues/1961,
there isn't a succinct way to change the "id" html field used for
sections

I could have used an add-on (https://github.com/GeeTransit/sphinx-better-subsection),
or made one myself, but I wanted to avoid extra dependencies for no
reason. (plus, I don't know how to make one myself.)

I could have used raw HTML for each heading, but that would immensely
pollute the rst file, which, while it is generated, is currently still
human-readable and it'd be nice for it to stay that way.

Also note that sphinx treats references as case-insensitive, which means
that they will all be lowercased in the resulting HTML. I envisioned
the ability to simply add #OptionName after the URL to get placed right
at the desired config option, which isn't possible without things such
as inline raw HTML.

To reconcile that, I added the ¶ paragraph buttons that can be used to
generate the link to the desired section, but since headings are not
actually used, they are faked and literally just a link following each
option, which means they stylistically don't match all other headings.

Also note that this sort-of assumes HTML output. I know Sphinx can
output other formats but I do not know if they are used. A non-html
output could embed unusable ¶ signs everywhere.

I'm okay with this patch being rejected in its current solution, or if
any of the above listed alternatives are better, they could be pursued
instead. In case the downsides of this solution are too much, I will
just create a feature request issue for this and maybe let someone more
experienced with Sphinx handle it, since this is still a feature I would
like to have. (and I do not want to deal with Sphinx at all after
battling with it for a whole day to produce a mediocre result.)

[HazardyKnusperkeks]

Full disclaimer: I have no idea what sphinx really is or how any of this stuff works, I still generate HTML from doxygen.

But I think the solution looks nice in code.

[HazardyKnusperkeks]

Another point, when looking at that code: All options have the version badge, and any new option should have it too. Maybe the script should just fail if self.version is not true?

[rymiel]

I consulted a little bit with a friend who has a little bit of experience with sphinx and they suggested making a simple custom extension for this. But given that there is no custom sphinx logic right now at all, I don't feel great adding something that novel to the whole of clang docs just for this page of clang-format

[rymiel]

This comment was removed by rymiel.

[aaron.ballman]

In D138446#3942006, @rymiel wrote:

I consulted a little bit with a friend who has a little bit of experience with sphinx and they suggested making a simple custom extension for this. But given that there is no custom sphinx logic right now at all, I don't feel great adding something that novel to the whole of clang docs just for this page of clang-format

Unless the custom extension is something that is committed to version control, fetched alongside the rest of the repo, and "just works" for folks without setup, I think it's best to avoid it. Otherwise we'll have to update the sphinx build bots, downstreams will have to react to it, and users will have a harder time building the docs locally. It's not that we can't do it if it's the right solution; it's that it's better to avoid something requiring manual intervention if we can.

As best I know, the way you've done things in this patch is the way Sphinx is expected to work for arbitrary anchors (despite being pretty janky IMO), so this LGTM!

[MyDeveloperDay]

So if I understand completely its so its easier to pick up an option and share as a hyperlink i.e. <.....>/llvm-project/clang/html/ClangFormatStyleOptions.html#allowallconstructorinitializersonnextline

LGTM

[aaron.ballman]

In D138446#4047487, @MyDeveloperDay wrote:

So if I understand completely its so its easier to pick up an option and share as a hyperlink i.e. <.....>/llvm-project/clang/html/ClangFormatStyleOptions.html#allowallconstructorinitializersonnextline

LGTM

Yup, that's how I read this -- easier to share links to specific options (which is really neat, I wish the command line reference for Clang did the same thing!).

clang/docs/ClangFormatStyleOptions.rst

 Configurable Format Style Options
 =================================
 
 This section lists the supported style options. Value type is specified for
 each option. For enumeration types possible values are specified both as a C++
 enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in
 the configuration (without a prefix: ``Auto``).
 
+.. _BasedOnStyle:
 
-**BasedOnStyle** (``String``)
+**BasedOnStyle** (``String``) :ref:`¶ <BasedOnStyle>`
   The style used for all options not specifically set in the configuration.
 
   This option is supported only in the :program:`clang-format` configuration
   (both within ``-style='{...}'`` and the ``.clang-format`` file).
 
   Possible values:
 
   * ``LLVM``
* ``InheritParentConfig``
     to that.
 
     With this option you can overwrite some parts of your main style for your
     subdirectories. This is also possible through the command line, e.g.:
     ``--style={BasedOnStyle: InheritParentConfig, ColumnLimit: 20}``
 
 .. START_FORMAT_STYLE_OPTIONS
 
-**AccessModifierOffset** (``Integer``) :versionbadge:`clang-format 3.3`
+.. _AccessModifierOffset:
+
+**AccessModifierOffset** (``Integer``) :versionbadge:`clang-format 3.3` :ref:`¶ <AccessModifierOffset>`
   The extra indent or outdent of access modifiers, e.g. ``public:``.
 
-**AlignAfterOpenBracket** (``BracketAlignmentStyle``) :versionbadge:`clang-format 3.8`
+.. _AlignAfterOpenBracket:
+
+**AlignAfterOpenBracket** (``BracketAlignmentStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignAfterOpenBracket>`
   If ``true``, horizontally aligns arguments after an open bracket.
 
   This applies to round brackets (parentheses), angle brackets and square
   brackets.
 
   Possible values:
 
   * ``BAS_Align`` (in configuration: ``Align``)
* ``BAS_BlockIndent`` (in configuration: ``BlockIndent``)
 
 
     .. warning:: 
 
      Note: This currently only applies to parentheses.
 
 
 
-**AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) :versionbadge:`clang-format 13`
+.. _AlignArrayOfStructures:
+
+**AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <AlignArrayOfStructures>`
   if not ``None``, when using initialization for an array of structs
   aligns the fields into columns.
 
   NOTE: As of clang-format 15 this option only applied to arrays with equal
   number of columns per row.
 
   Possible values:
 
.. code-block:: c++
           { 7,     5,    "!!"}
       };
 
   * ``AIAS_None`` (in configuration: ``None``)
     Don't align array initializer columns.
 
 
 
-**AlignConsecutiveAssignments** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8`
+.. _AlignConsecutiveAssignments:
+
+**AlignConsecutiveAssignments** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveAssignments>`
   Style of aligning consecutive assignments.
 
   ``Consecutive`` will result in formattings like:
 
   .. code-block:: c++
 
     int a            = 1;
     int somelongname = 2;
.. code-block:: c++
       false:
       a >>= 2;
       bbb = 2;
 
       a     = 2;
       bbb >>= 2;
 
 
-**AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11`
+.. _AlignConsecutiveBitFields:
+
+**AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11` :ref:`¶ <AlignConsecutiveBitFields>`
   Style of aligning consecutive bit fields.
 
   ``Consecutive`` will align the bitfield separators of consecutive lines.
   This will result in formattings like:
 
   .. code-block:: c++
 
     int aaaa : 1;
.. code-block:: c++
       false:
       a >>= 2;
       bbb = 2;
 
       a     = 2;
       bbb >>= 2;
 
 
-**AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8`
+.. _AlignConsecutiveDeclarations:
+
+**AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveDeclarations>`
   Style of aligning consecutive declarations.
 
   ``Consecutive`` will align the declaration names of consecutive lines.
   This will result in formattings like:
 
   .. code-block:: c++
 
     int         aaaa = 12;
.. code-block:: c++
       false:
       a >>= 2;
       bbb = 2;
 
       a     = 2;
       bbb >>= 2;
 
 
-**AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9`
+.. _AlignConsecutiveMacros:
+
+**AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AlignConsecutiveMacros>`
   Style of aligning consecutive macro definitions.
 
   ``Consecutive`` will result in formattings like:
 
   .. code-block:: c++
 
     #define SHORT_NAME       42
     #define LONGER_NAME      0x007f
.. code-block:: c++
       false:
       a >>= 2;
       bbb = 2;
 
       a     = 2;
       bbb >>= 2;
 
 
-**AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5`
+.. _AlignEscapedNewlines:
+
+**AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ <AlignEscapedNewlines>`
   Options for aligning backslashes in escaped newlines.
 
   Possible values:
 
   * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
     Don't align escaped newlines.
 
     .. code-block:: c++
.. code-block:: c++
 
       #define A                                                                      \
         int aaaa;                                                                    \
         int b;                                                                       \
         int dddddddddd;
 
 
 
-**AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5`
+.. _AlignOperands:
+
+**AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AlignOperands>`
   If ``true``, horizontally align operands of binary and ternary
   expressions.
 
   Possible values:
 
   * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
     Do not align operands of binary and ternary expressions.
     The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
* ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
 
     .. code-block:: c++
 
       int aaa = bbbbbbbbbbbbbbb
               + ccccccccccccccc;
 
 
 
-**AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7`
+.. _AlignTrailingComments:
+
+**AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlignTrailingComments>`
   Control of trailing comments.
 
   NOTE: As of clang-format 16 this option is not a bool but can be set
   to the options. Conventional bool options still can be parsed as before.
 
 
   .. code-block:: yaml
 
.. code-block:: c++
       int a;  // these are
 
       int ab; // aligned
 
 
       int abcdef; // but this isn't
 
 
-**AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9`
+.. _AllowAllArgumentsOnNextLine:
+
+**AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllArgumentsOnNextLine>`
   If a function call or braced initializer list doesn't fit on a
   line, allow putting all arguments onto the next line, even if
   ``BinPackArguments`` is ``false``.
 
   .. code-block:: c++
 
     true:
     callFunction(
         a, b, c, d);
 
     false:
     callFunction(a,
                  b,
                  c,
                  d);
 
-**AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9`
+.. _AllowAllConstructorInitializersOnNextLine:
+
+**AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllConstructorInitializersOnNextLine>`
   This option is **deprecated**. See ``NextLine`` of
   ``PackConstructorInitializers``.
 
-**AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3`
+.. _AllowAllParametersOfDeclarationOnNextLine:
+
+**AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowAllParametersOfDeclarationOnNextLine>`
   If the function declaration doesn't fit on a line,
   allow putting all parameters of a function declaration onto
   the next line even if ``BinPackParameters`` is ``false``.
 
   .. code-block:: c++
 
     true:
     void myFunction(
         int a, int b, int c, int d, int e);
 
     false:
     void myFunction(int a,
                     int b,
                     int c,
                     int d,
                     int e);
 
-**AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5`
+.. _AllowShortBlocksOnASingleLine:
+
+**AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortBlocksOnASingleLine>`
   Dependent on the value, ``while (true) { continue; }`` can be put on a
   single line.
 
   Possible values:
 
   * ``SBS_Never`` (in configuration: ``Never``)
     Never merge blocks into a single line.
 
* ``SBS_Always`` (in configuration: ``Always``)
 
     .. code-block:: c++
 
       while (true) {}
       while (true) { continue; }
 
 
 
-**AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6`
+.. _AllowShortCaseLabelsOnASingleLine:
+
+**AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6` :ref:`¶ <AllowShortCaseLabelsOnASingleLine>`
   If ``true``, short case labels will be contracted to a single line.
 
   .. code-block:: c++
 
     true:                                   false:
     switch (a) {                    vs.     switch (a) {
     case 1: x = 1; break;                   case 1:
     case 2: return;                           x = 1;
     }                                         break;
                                             case 2:
                                               return;
                                             }
 
-**AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11`
+.. _AllowShortEnumsOnASingleLine:
+
+**AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <AllowShortEnumsOnASingleLine>`
   Allow short enums on a single line.
 
   .. code-block:: c++
 
     true:
     enum { A, B } myEnum;
 
     false:
     enum {
       A,
       B
     } myEnum;
 
-**AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5`
+.. _AllowShortFunctionsOnASingleLine:
+
+**AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortFunctionsOnASingleLine>`
   Dependent on the value, ``int f() { return 0; }`` can be put on a
   single line.
 
   Possible values:
 
   * ``SFS_None`` (in configuration: ``None``)
     Never merge functions into a single line.
 
.. code-block:: c++
 
       class Foo {
         void f() { foo(); }
       };
       void f() { bar(); }
 
 
 
-**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3`
+.. _AllowShortIfStatementsOnASingleLine:
+
+**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowShortIfStatementsOnASingleLine>`
   Dependent on the value, ``if (a) return;`` can be put on a single line.
 
   Possible values:
 
   * ``SIS_Never`` (in configuration: ``Never``)
     Never put short ifs on the same line.
 
     .. code-block:: c++
.. code-block:: c++
 
       if (c) return;
       else {
         return;
       }
 
 
 
-**AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9`
+.. _AllowShortLambdasOnASingleLine:
+
+**AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AllowShortLambdasOnASingleLine>`
   Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
   single line.
 
   Possible values:
 
   * ``SLS_None`` (in configuration: ``None``)
     Never merge lambdas into a single line.
 
* ``SLS_All`` (in configuration: ``All``)
 
     .. code-block:: c++
 
       auto lambda = [](int a) {};
       auto lambda2 = [](int a) { return a; };
 
 
 
-**AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _AllowShortLoopsOnASingleLine:
+
+**AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <AllowShortLoopsOnASingleLine>`
   If ``true``, ``while (true) continue;`` can be put on a single
   line.
 
-**AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7`
+.. _AlwaysBreakAfterDefinitionReturnType:
+
+**AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlwaysBreakAfterDefinitionReturnType>`
   The function definition return type breaking style to use.  This
   option is **deprecated** and is retained for backwards compatibility.
 
   Possible values:
 
   * ``DRTBS_None`` (in configuration: ``None``)
     Break after return type automatically.
     ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 
   * ``DRTBS_All`` (in configuration: ``All``)
     Always break after the return type.
 
   * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
     Always break after the return types of top-level functions.
 
 
 
-**AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.8`
+.. _AlwaysBreakAfterReturnType:
+
+**AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlwaysBreakAfterReturnType>`
   The function declaration return type breaking style to use.
 
   Possible values:
 
   * ``RTBS_None`` (in configuration: ``None``)
     Break after return type automatically.
     ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 
.. code-block:: c++
       int f();
       int
       f() {
         return 1;
       }
 
 
 
-**AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4`
+.. _AlwaysBreakBeforeMultilineStrings:
+
+**AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakBeforeMultilineStrings>`
   If ``true``, always break before multiline string literals.
 
   This flag is mean to make cases where there are multiple multiline strings
   in a file look more consistent. Thus, it will only take effect if wrapping
   the string at that point leads to it being indented
   ``ContinuationIndentWidth`` spaces from the start of the line.
 
   .. code-block:: c++
 
      true:                                  false:
      aaaa =                         vs.     aaaa = "bbbb"
          "bbbb"                                    "cccc";
          "cccc";
 
-**AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 3.4`
+.. _AlwaysBreakTemplateDeclarations:
+
+**AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakTemplateDeclarations>`
   The template declaration breaking style to use.
 
   Possible values:
 
   * ``BTDS_No`` (in configuration: ``No``)
     Do not force break before declaration.
     ``PenaltyBreakTemplateDeclaration`` is taken into account.
 
.. code-block:: c++
        }
        template <typename T>
        T foo(int aaaaaaaaaaaaaaaaaaaaa,
              int bbbbbbbbbbbbbbbbbbbbb) {
        }
 
 
 
-**AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12`
+.. _AttributeMacros:
+
+**AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <AttributeMacros>`
   A vector of strings that should be interpreted as attributes/qualifiers
   instead of identifiers. This can be useful for language extensions or
   static analyzer annotations.
 
   For example:
 
   .. code-block:: c++
 
     x = (char *__capability)&y;
     int function(void) __ununsed;
     void only_writes_to_buffer(char *__output buffer);
 
   In the .clang-format configuration file, this can be configured like:
 
   .. code-block:: yaml
 
     AttributeMacros: ['__capability', '__output', '__ununsed']
 
-**BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _BinPackArguments:
+
+**BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackArguments>`
   If ``false``, a function call's arguments will either be all on the
   same line or will have one line each.
 
   .. code-block:: c++
 
     true:
     void f() {
       f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
         aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
     }
 
     false:
     void f() {
       f(aaaaaaaaaaaaaaaaaaaa,
         aaaaaaaaaaaaaaaaaaaa,
         aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
     }
 
-**BinPackParameters** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _BinPackParameters:
+
+**BinPackParameters** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackParameters>`
   If ``false``, a function declaration's or function definition's
   parameters will either all be on the same line or will have one line each.
 
   .. code-block:: c++
 
     true:
     void f(int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaa,
            int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
 
     false:
     void f(int aaaaaaaaaaaaaaaaaaaa,
            int aaaaaaaaaaaaaaaaaaaa,
            int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
 
-**BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12`
+.. _BitFieldColonSpacing:
+
+**BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BitFieldColonSpacing>`
   The BitFieldColonSpacingStyle to use for bitfields.
 
   Possible values:
 
   * ``BFCS_Both`` (in configuration: ``Both``)
     Add one space on each side of the ``:``
 
     .. code-block:: c++
* ``BFCS_After`` (in configuration: ``After``)
     needed for ``AlignConsecutiveBitFields``).
 
     .. code-block:: c++
 
       unsigned bf: 2;
 
 
 
-**BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8`
+.. _BraceWrapping:
+
+**BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8` :ref:`¶ <BraceWrapping>`
   Control of individual brace wrapping cases.
 
   If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how
   each individual brace case should be handled. Otherwise, this is ignored.
 
   .. code-block:: yaml
 
     # Example of usage:
* ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
     .. code-block:: c++
 
       false:               true:
       namespace Foo   vs.  namespace Foo
       {}                   {
                            }
 
 
-**BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16`
+.. _BreakAfterAttributes:
+
+**BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakAfterAttributes>`
   Break after a group of C++11 attributes before a function
   declaration/definition name.
 
   Possible values:
 
   * ``ABS_Always`` (in configuration: ``Always``)
     Always break after attributes.
 
* ``ABS_Never`` (in configuration: ``Never``)
 
     .. code-block:: c++
 
       [[nodiscard]] inline int f();
       [[gnu::const]] [[nodiscard]] int g();
 
 
 
-**BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8`
+.. _BreakAfterJavaFieldAnnotations:
+
+**BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <BreakAfterJavaFieldAnnotations>`
   Break after each annotation on a field in Java files.
 
   .. code-block:: java
 
      true:                                  false:
      @Partial                       vs.     @Partial @Mock DataLoad loader;
      @Mock
      DataLoad loader;
 
-**BreakArrays** (``Boolean``) :versionbadge:`clang-format 16`
+.. _BreakArrays:
+
+**BreakArrays** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <BreakArrays>`
   If ``true``, clang-format will always break after a Json array `[`
   otherwise it will scan until the closing `]` to determine if it should add
   newlines between elements (prettier compatible).
 
   NOTE: This is currently only for formatting JSON.
 
   .. code-block:: c++
 
      true:                                  false:
      [                          vs.      [1, 2, 3, 4]
        1,
        2,
        3,
        4
      ]
 
-**BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6`
+.. _BreakBeforeBinaryOperators:
+
+**BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6` :ref:`¶ <BreakBeforeBinaryOperators>`
   The way to wrap binary operators.
 
   Possible values:
 
   * ``BOS_None`` (in configuration: ``None``)
     Break after operators.
 
     .. code-block:: c++
.. code-block:: c++
        bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                             + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                         == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                     && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                            > ccccccccccccccccccccccccccccccccccccccccc;
 
 
 
-**BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7`
+.. _BreakBeforeBraces:
+
+**BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeBraces>`
   The brace breaking style to use.
 
   Possible values:
 
   * ``BS_Attach`` (in configuration: ``Attach``)
     Always attach braces to surrounding context.
 
     .. code-block:: c++
.. code-block:: c++
       void bar() { foo(true); }
       } // namespace N
 
   * ``BS_Custom`` (in configuration: ``Custom``)
     Configure each individual brace in `BraceWrapping`.
 
 
 
-**BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12`
+.. _BreakBeforeConceptDeclarations:
+
+**BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BreakBeforeConceptDeclarations>`
   The concept declaration style to use.
 
   Possible values:
 
   * ``BBCDS_Never`` (in configuration: ``Never``)
     Keep the template declaration line together with ``concept``.
 
     .. code-block:: c++
* ``BBCDS_Always`` (in configuration: ``Always``)
 
     .. code-block:: c++
 
       template <typename T>
       concept C = ...;
 
 
 
-**BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16`
+.. _BreakBeforeInlineASMColon:
+
+**BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakBeforeInlineASMColon>`
   The inline ASM colon style to use.
 
   Possible values:
 
   * ``BBIAS_Never`` (in configuration: ``Never``)
     No break before inline ASM colon.
 
     .. code-block:: c++
* ``BBIAS_Always`` (in configuration: ``Always``)
     .. code-block:: c++
 
        asm volatile("string",
                     :
                     : val);
 
 
 
-**BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _BreakBeforeTernaryOperators:
+
+**BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeTernaryOperators>`
   If ``true``, ternary operators will be placed after line breaks.
 
   .. code-block:: c++
 
      true:
      veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
          ? firstValue
          : SecondValueVeryVeryVeryVeryLong;
 
      false:
      veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
          firstValue :
          SecondValueVeryVeryVeryVeryLong;
 
-**BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5`
+.. _BreakConstructorInitializers:
+
+**BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5` :ref:`¶ <BreakConstructorInitializers>`
   The break constructor initializers style to use.
 
   Possible values:
 
   * ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
     Break constructor initializers before the colon and after the commas.
 
     .. code-block:: c++
* ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
     .. code-block:: c++
 
        Constructor() :
            initializer1(),
            initializer2()
 
 
 
-**BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7`
+.. _BreakInheritanceList:
+
+**BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7` :ref:`¶ <BreakInheritanceList>`
   The inheritance list style to use.
 
   Possible values:
 
   * ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
     Break inheritance list before the colon and after the commas.
 
     .. code-block:: c++
* ``BILS_AfterComma`` (in configuration: ``AfterComma``)
     .. code-block:: c++
 
        class Foo : Base1,
                    Base2
        {};
 
 
 
-**BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9`
+.. _BreakStringLiterals:
+
+**BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <BreakStringLiterals>`
   Allow breaking string literals when formatting.
 
   .. code-block:: c++
 
      true:
      const char* x = "veryVeryVeryVeryVeryVe"
                      "ryVeryVeryVeryVeryVery"
                      "VeryLongString";
 
      false:
      const char* x =
        "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
 
-**ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _ColumnLimit:
+
+**ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ColumnLimit>`
   The column limit.
 
   A column limit of ``0`` means that there is no column limit. In this case,
   clang-format will respect the input's line breaking decisions within
   statements unless they contradict other rules.
 
-**CommentPragmas** (``String``) :versionbadge:`clang-format 3.7`
+.. _CommentPragmas:
+
+**CommentPragmas** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <CommentPragmas>`
   A regular expression that describes comments with special meaning,
   which should not be split into lines or otherwise changed.
 
   .. code-block:: c++
 
      // CommentPragmas: '^ FOOBAR pragma:'
      // Will leave the following line unaffected
      #include <vector> // FOOBAR pragma: keep
 
-**CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5`
+.. _CompactNamespaces:
+
+**CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <CompactNamespaces>`
   If ``true``, consecutive namespace declarations will be on the same
   line. If ``false``, each namespace is declared on a new line.
 
   .. code-block:: c++
 
     true:
     namespace Foo { namespace Bar {
     }}
 
     false:
     namespace Foo {
     namespace Bar {
     }
     }
 
   If it does not fit on a single line, the overflowing namespaces get
   wrapped:
 
   .. code-block:: c++
 
     namespace Foo { namespace Bar {
     namespace Extra {
     }}}
 
-**ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _ConstructorInitializerAllOnOneLineOrOnePerLine:
+
+**ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerAllOnOneLineOrOnePerLine>`
   This option is **deprecated**. See ``CurrentLine`` of
   ``PackConstructorInitializers``.
 
-**ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _ConstructorInitializerIndentWidth:
+
+**ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerIndentWidth>`
   The number of characters to use for indentation of constructor
   initializer lists as well as inheritance lists.
 
-**ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _ContinuationIndentWidth:
+
+**ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ContinuationIndentWidth>`
   Indent width for line continuations.
 
   .. code-block:: c++
 
      ContinuationIndentWidth: 2
 
      int i =         //  VeryVeryVeryVeryVeryLongComment
        longFunction( // Again a long comment
          arg);
 
-**Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4`
+.. _Cpp11BracedListStyle:
+
+**Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <Cpp11BracedListStyle>`
   If ``true``, format braced lists as best suited for C++11 braced
   lists.
 
   Important differences:
   - No spaces inside the braced list.
   - No line break before the closing brace.
   - Indentation with the continuation indent, not with the block indent.
 
   Fundamentally, C++11 braced lists are formatted exactly like function
   calls would be formatted in their place. If the braced list follows a name
   (e.g. a type or variable name), clang-format formats as if the ``{}`` were
   the parentheses of a function call with that name. If there is no name,
   a zero-length name is assumed.
 
   .. code-block:: c++
 
      true:                                  false:
      vector<int> x{1, 2, 3, 4};     vs.     vector<int> x{ 1, 2, 3, 4 };
      vector<T> x{{}, {}, {}, {}};           vector<T> x{ {}, {}, {}, {} };
      f(MyMap[{composite, key}]);            f(MyMap[{ composite, key }]);
      new int[3]{1, 2, 3};                   new int[3]{ 1, 2, 3 };
 
-**DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10`
+.. _DeriveLineEnding:
+
+**DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <DeriveLineEnding>`
   Analyze the formatted file for the most used line ending (``\r\n``
   or ``\n``). ``UseCRLF`` is only used as a fallback if none can be derived.
 
-**DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _DerivePointerAlignment:
+
+**DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DerivePointerAlignment>`
   If ``true``, analyze the formatted file for the most common
   alignment of ``&`` and ``*``.
   Pointer and reference alignment styles are going to be updated according
   to the preferences found in the file.
   ``PointerAlignment`` is then used only as fallback.
 
-**DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _DisableFormat:
+
+**DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DisableFormat>`
   Disables formatting completely.
 
-**EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13`
+.. _EmptyLineAfterAccessModifier:
+
+**EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ <EmptyLineAfterAccessModifier>`
   Defines when to put an empty line after access modifiers.
   ``EmptyLineBeforeAccessModifier`` configuration handles the number of
   empty lines between two access modifiers.
 
   Possible values:
 
   * ``ELAAMS_Never`` (in configuration: ``Never``)
     Remove all empty lines after access modifiers.
.. code-block:: c++
       private:
 
       protected:
 
       };
 
 
 
-**EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12`
+.. _EmptyLineBeforeAccessModifier:
+
+**EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12` :ref:`¶ <EmptyLineBeforeAccessModifier>`
   Defines in which cases to put empty line before access modifiers.
 
   Possible values:
 
   * ``ELBAMS_Never`` (in configuration: ``Never``)
     Remove all empty lines before access modifiers.
 
     .. code-block:: c++
.. code-block:: c++
 
       private:
 
       protected:
       };
 
 
 
-**ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _ExperimentalAutoDetectBinPacking:
+
+**ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ExperimentalAutoDetectBinPacking>`
   If ``true``, clang-format detects whether function calls and
   definitions are formatted with one parameter per line.
 
   Each call can be bin-packed, one-per-line or inconclusive. If it is
   inconclusive, e.g. completely on one line, but a decision needs to be
   made, clang-format analyzes whether there are other bin-packed cases in
   the input file and act accordingly.
 
   NOTE: This is an experimental flag, that might go away or be renamed. Do
   not use this in config files, etc. Use at your own risk.
 
-**FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5`
+.. _FixNamespaceComments:
+
+**FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <FixNamespaceComments>`
   If ``true``, clang-format adds missing namespace end comments for
   namespaces and fixes invalid existing ones. This doesn't affect short
   namespaces, which are controlled by ``ShortNamespaceLines``.
 
   .. code-block:: c++
 
      true:                                  false:
      namespace longNamespace {      vs.     namespace longNamespace {
      void foo();                            void foo();
      void bar();                            void bar();
      } // namespace a                       }
      namespace shortNamespace {             namespace shortNamespace {
      void baz();                            void baz();
      }                                      }
 
-**ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7`
+.. _ForEachMacros:
+
+**ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7` :ref:`¶ <ForEachMacros>`
   A vector of macros that should be interpreted as foreach loops
   instead of as function calls.
 
   These are expected to be macros of the form:
 
   .. code-block:: c++
 
     FOREACH(<variable-declaration>, ...)
       <loop-body>
 
   In the .clang-format configuration file, this can be configured like:
 
   .. code-block:: yaml
 
     ForEachMacros: ['RANGES_FOR', 'FOREACH']
 
   For example: BOOST_FOREACH.
 
-**IfMacros** (``List of Strings``) :versionbadge:`clang-format 13`
+.. _IfMacros:
+
+**IfMacros** (``List of Strings``) :versionbadge:`clang-format 13` :ref:`¶ <IfMacros>`
   A vector of macros that should be interpreted as conditionals
   instead of as function calls.
 
   These are expected to be macros of the form:
 
   .. code-block:: c++
 
     IF(...)
       <conditional-body>
     else IF(...)
       <conditional-body>
 
   In the .clang-format configuration file, this can be configured like:
 
   .. code-block:: yaml
 
     IfMacros: ['IF']
 
   For example: `KJ_IF_MAYBE
   <https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes>`_
 
-**IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6`
+.. _IncludeBlocks:
+
+**IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IncludeBlocks>`
   Dependent on the value, multiple ``#include`` blocks can be sorted
   as one and divided based on category.
 
   Possible values:
 
   * ``IBS_Preserve`` (in configuration: ``Preserve``)
     Sort each ``#include`` block separately.
 
.. code-block:: c++
 
        #include "b.h"               into      #include "a.h"
                                               #include "b.h"
        #include <lib/main.h>
        #include "a.h"                         #include <lib/main.h>
 
 
 
-**IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8`
+.. _IncludeCategories:
+
+**IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8` :ref:`¶ <IncludeCategories>`
   Regular expressions denoting the different ``#include`` categories
   used for ordering ``#includes``.
 
   `POSIX extended
   <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
   regular expressions are supported.
 
   These regular expressions are matched against the filename of an include
IncludeCategories:
       - Regex:           '^((<|")(gtest|gmock|isl|json)/)'
         Priority:        3
       - Regex:           '<[[:alnum:].]+>'
         Priority:        4
       - Regex:           '.*'
         Priority:        1
         SortPriority:    0
 
-**IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9`
+.. _IncludeIsMainRegex:
+
+**IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9` :ref:`¶ <IncludeIsMainRegex>`
   Specify a regular expression of suffixes that are allowed in the
   file-to-main-include mapping.
 
   When guessing whether a #include is the "main" include (to assign
   category 0, see above), use this regex of allowed suffixes to the header
   stem. A partial match is done, so that:
   - "" means "arbitrary suffix"
   - "$" means "no suffix"
 
   For example, if configured to "(_test)?$", then a header a.h would be seen
   as the "main" include in both a.cc and a_test.cc.
 
-**IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10`
+.. _IncludeIsMainSourceRegex:
+
+**IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10` :ref:`¶ <IncludeIsMainSourceRegex>`
   Specify a regular expression for files being formatted
   that are allowed to be considered "main" in the
   file-to-main-include mapping.
 
   By default, clang-format considers files as "main" only when they end
   with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
   extensions.
   For these files a guessing of "main" include takes place
   (to assign category 0, see above). This config option allows for
   additional suffixes and extensions for files to be considered as "main".
 
   For example, if this option is configured to ``(Impl\.hpp)$``,
   then a file ``ClassImpl.hpp`` is considered "main" (in addition to
   ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
   include file" logic will be executed (with *IncludeIsMainRegex* setting
   also being respected in later phase). Without this option set,
   ``ClassImpl.hpp`` would not have the main include file put on top
   before any other include.
 
-**IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13`
+.. _IndentAccessModifiers:
+
+**IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13` :ref:`¶ <IndentAccessModifiers>`
   Specify whether access modifiers should have their own indentation level.
 
   When ``false``, access modifiers are indented (or outdented) relative to
   the record members, respecting the ``AccessModifierOffset``. Record
   members are indented one level below the record.
   When ``true``, access modifiers get their own indentation level. As a
   consequence, record members are always indented 2 levels below the record,
   regardless of the access modifier presence. Value of the
class C {                      vs.     class C {
        };                                       };
      public:                                  public:
        C();                                     C();
      };                                     };
      void foo() {                           void foo() {
        return 1;                              return 1;
      }                                      }
 
-**IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11`
+.. _IndentCaseBlocks:
+
+**IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <IndentCaseBlocks>`
   Indent case label blocks one level from the case label.
 
   When ``false``, the block following the case label uses the same
   indentation level as for the case label, treating the case label the same
   as an if-statement.
   When ``true``, the block gets indented as a scope block.
 
   .. code-block:: c++
 
      false:                                 true:
      switch (fool) {                vs.     switch (fool) {
      case 1: {                              case 1:
        bar();                                 {
      } break;                                   bar();
      default: {                               }
        plop();                                break;
      }                                      default:
      }                                        {
                                                 plop();
                                               }
                                             }
 
-**IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3`
+.. _IndentCaseLabels:
+
+**IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <IndentCaseLabels>`
   Indent case labels one level from the switch statement.
 
   When ``false``, use the same indentation level as for the switch
   statement. Switch statement body is always indented one level more than
   case labels (except the first block following the case label, which
   itself indents the code - unless IndentCaseBlocks is enabled).
 
   .. code-block:: c++
 
      false:                                 true:
      switch (fool) {                vs.     switch (fool) {
      case 1:                                  case 1:
        bar();                                   bar();
        break;                                   break;
      default:                                 default:
        plop();                                  plop();
      }                                      }
 
-**IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11`
+.. _IndentExternBlock:
+
+**IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11` :ref:`¶ <IndentExternBlock>`
   IndentExternBlockStyle is the type of indenting of extern blocks.
 
   Possible values:
 
   * ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
     Backwards compatible with AfterExternBlock's indenting.
 
     .. code-block:: c++
* ``IEBS_Indent`` (in configuration: ``Indent``)
     .. code-block:: c++
 
         extern "C" {
           void foo();
         }
 
 
 
-**IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10`
+.. _IndentGotoLabels:
+
+**IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <IndentGotoLabels>`
   Indent goto labels.
 
   When ``false``, goto labels are flushed left.
 
   .. code-block:: c++
 
      true:                                  false:
      int f() {                      vs.     int f() {
        if (foo()) {                           if (foo()) {
        label1:                              label1:
          bar();                                 bar();
        }                                      }
      label2:                                label2:
        return 1;                              return 1;
      }                                      }
 
-**IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6`
+.. _IndentPPDirectives:
+
+**IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IndentPPDirectives>`
   The preprocessor directive indenting style to use.
 
   Possible values:
 
   * ``PPDIS_None`` (in configuration: ``None``)
     Does not indent any directives.
 
     .. code-block:: c++
.. code-block:: c++
        #if FOO
          #if BAR
            #include <foo>
          #endif
        #endif
 
 
 
-**IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15`
+.. _IndentRequiresClause:
+
+**IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <IndentRequiresClause>`
   Indent the requires clause in a template. This only applies when
   ``RequiresClausePosition`` is ``OwnLine``, or ``WithFollowing``.
 
   In clang-format 12, 13 and 14 it was named ``IndentRequires``.
 
   .. code-block:: c++
 
      true:
      template <typename It>
        requires Iterator<It>
      void sort(It begin, It end) {
        //....
      }
 
      false:
      template <typename It>
      requires Iterator<It>
      void sort(It begin, It end) {
        //....
      }
 
-**IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _IndentWidth:
+
+**IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWidth>`
   The number of columns to use for indentation.
 
   .. code-block:: c++
 
      IndentWidth: 3
 
      void f() {
         someFunction();
         if (true, false) {
            f();
         }
      }
 
-**IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _IndentWrappedFunctionNames:
+
+**IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWrappedFunctionNames>`
   Indent if a function definition or declaration is wrapped after the
   type.
 
   .. code-block:: c++
 
      true:
      LoooooooooooooooooooooooooooooooooooooooongReturnType
          LoooooooooooooooooooooooooooooooongFunctionDeclaration();
 
      false:
      LoooooooooooooooooooooooooooooooooooooooongReturnType
      LoooooooooooooooooooooooooooooooongFunctionDeclaration();
 
-**InsertBraces** (``Boolean``) :versionbadge:`clang-format 15`
+.. _InsertBraces:
+
+**InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <InsertBraces>`
   Insert braces after control statements (``if``, ``else``, ``for``, ``do``,
   and ``while``) in C++ unless the control statements are inside macro
   definitions or the braces would enclose preprocessor directives.
 
   .. warning:: 
 
    Setting this option to `true` could lead to incorrect code formatting due
    to clang-format's lack of complete semantic information. As such, extra
while (i--)                      vs.      while (i--) {
         handleAttr(A);                            handleAttr(A);
                                                 }
                                               }
 
     do                               vs.      do {
       --i;                                      --i;
     while (i);                                } while (i);
 
-**InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16`
+.. _InsertNewlineAtEOF:
+
+**InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <InsertNewlineAtEOF>`
   Insert a newline at end of file if missing.
 
-**InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11`
+.. _InsertTrailingCommas:
+
+**InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11` :ref:`¶ <InsertTrailingCommas>`
   If set to ``TCS_Wrapped`` will insert trailing commas in container
   literals (arrays and objects) that wrap across multiple lines.
   It is currently only available for JavaScript
   and disabled by default ``TCS_None``.
   ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
   as inserting the comma disables bin-packing.
 
   .. code-block:: c++
* ``TCS_Wrapped`` (in configuration: ``Wrapped``)
     Insert trailing commas in container literals that were wrapped over
     multiple lines. Note that this is conceptually incompatible with
     bin-packing, because the trailing comma is used as an indicator
     that a container should be formatted one-per-line (i.e. not bin-packed).
     So inserting a trailing comma counteracts bin-packing.
 
 
 
-**IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16`
+.. _IntegerLiteralSeparator:
+
+**IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16` :ref:`¶ <IntegerLiteralSeparator>`
   Format integer literal separators (``'`` for C++ and ``_`` for C#, Java,
   and JavaScript).
 
   Nested configuration flags:
 
   Separator format of integer literals of different bases.
 
   If negative, remove separators. If  ``0``, leave the literal as is. If
* ``int8_t Hex`` Format separators in hexadecimal literals.
 
     .. code-block:: text
 
       /* -1: */ h = 0xDEADBEEFDEADBEEFuz;
       /*  0: */ h = 0xDEAD'BEEF'DE'AD'BEE'Fuz;
       /*  2: */ h = 0xDE'AD'BE'EF'DE'AD'BE'EFuz;
 
 
-**JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8`
+.. _JavaImportGroups:
+
+**JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <JavaImportGroups>`
   A vector of prefixes ordered by the desired groups for Java imports.
 
   One group's prefix can be a subset of another - the longest prefix is
   always matched. Within a group, the imports are ordered lexicographically.
   Static imports are grouped separately and follow the same group rules.
   By default, static imports are placed before non-static imports,
   but this behavior is changed by another option,
   ``SortJavaStaticImport``.
.. code-block:: java
      import com.example.ClassA;
      import com.example.Test;
      import com.example.a.ClassB;
 
      import com.test.ClassC;
 
      import org.example.ClassD;
 
-**JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9`
+.. _JavaScriptQuotes:
+
+**JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptQuotes>`
   The JavaScriptQuoteStyle to use for JavaScript strings.
 
   Possible values:
 
   * ``JSQS_Leave`` (in configuration: ``Leave``)
     Leave string quotes as they are.
 
     .. code-block:: js
* ``JSQS_Double`` (in configuration: ``Double``)
 
     .. code-block:: js
 
        string1 = "foo";
        string2 = "bar";
 
 
 
-**JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9`
+.. _JavaScriptWrapImports:
+
+**JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptWrapImports>`
   Whether to wrap JavaScript import/export statements.
 
   .. code-block:: js
 
      true:
      import {
          VeryLongImportsAreAnnoying,
          VeryLongImportsAreAnnoying,
          VeryLongImportsAreAnnoying,
      } from 'some/module.js'
 
      false:
      import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
 
-**KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _KeepEmptyLinesAtTheStartOfBlocks:
+
+**KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <KeepEmptyLinesAtTheStartOfBlocks>`
   If true, the empty line at the start of blocks is kept.
 
   .. code-block:: c++
 
      true:                                  false:
      if (foo) {                     vs.     if (foo) {
                                               bar();
        bar();                               }
      }
 
-**LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13`
+.. _LambdaBodyIndentation:
+
+**LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13` :ref:`¶ <LambdaBodyIndentation>`
   The indentation style of lambda bodies. ``Signature`` (the default)
   causes the lambda body to be indented one additional level relative to
   the indentation level of the signature. ``OuterScope`` forces the lambda
   body to be indented one additional level relative to the parent scope
   containing the lambda signature. For callback-heavy code, it may improve
   readability to have the signature indented two levels and to use
   ``OuterScope``. The KJ style guide requires ``OuterScope``.
   `KJ style guide
.. code-block:: c++
 
        someMethod(
            [](SomeReallyLongLambdaSignatureArgument foo) {
          return;
        });
 
 
 
-**Language** (``LanguageKind``) :versionbadge:`clang-format 3.5`
+.. _Language:
+
+**Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ <Language>`
   Language, this format style is targeted at.
 
   Possible values:
 
   * ``LK_None`` (in configuration: ``None``)
     Do not use.
 
   * ``LK_Cpp`` (in configuration: ``Cpp``)
**Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ <Language>`
 
   * ``LK_Verilog`` (in configuration: ``Verilog``)
     Should be used for Verilog and SystemVerilog.
     https://standards.ieee.org/ieee/1800/6700/
     https://sci-hub.st/10.1109/IEEESTD.2018.8299595
 
 
 
-**MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7`
+.. _MacroBlockBegin:
+
+**MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockBegin>`
   A regular expression matching macros that start a block.
 
   .. code-block:: c++
 
      # With:
      MacroBlockBegin: "^NS_MAP_BEGIN|\
      NS_TABLE_HEAD$"
      MacroBlockEnd: "^\
.. code-block:: c++
      NS_MAP_BEGIN
      foo();
      NS_MAP_END
 
      NS_TABLE_HEAD
      bar();
      NS_TABLE_FOO_END
 
-**MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7`
+.. _MacroBlockEnd:
+
+**MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockEnd>`
   A regular expression matching macros that end a block.
 
-**MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _MaxEmptyLinesToKeep:
+
+**MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <MaxEmptyLinesToKeep>`
   The maximum number of consecutive empty lines to keep.
 
   .. code-block:: c++
 
      MaxEmptyLinesToKeep: 1         vs.     MaxEmptyLinesToKeep: 0
      int f() {                              int f() {
        int = 1;                                 int i = 1;
                                                 i = foo();
        i = foo();                               return i;
                                             }
        return i;
      }
 
-**NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7`
+.. _NamespaceIndentation:
+
+**NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7` :ref:`¶ <NamespaceIndentation>`
   The indentation used for namespaces.
 
   Possible values:
 
   * ``NI_None`` (in configuration: ``None``)
     Don't indent in namespaces.
 
     .. code-block:: c++
.. code-block:: c++
          int i;
          namespace in {
            int i;
          }
        }
 
 
 
-**NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9`
+.. _NamespaceMacros:
+
+**NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <NamespaceMacros>`
   A vector of macros which are used to open namespace blocks.
 
   These are expected to be macros of the form:
 
   .. code-block:: c++
 
     NAMESPACE(<namespace-name>, ...) {
       <namespace-content>
     }
 
   For example: TESTSUITE
 
-**ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7`
+.. _ObjCBinPackProtocolList:
+
+**ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ <ObjCBinPackProtocolList>`
   Controls bin-packing Objective-C protocol conformance list
   items into as few lines as possible when they go over ``ColumnLimit``.
 
   If ``Auto`` (the default), delegates to the value in
   ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
   protocol conformance list items into as few lines as possible
   whenever they go over ``ColumnLimit``.
 
**ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ <ObjCBinPackProtocolList>`
   * ``BPS_Always`` (in configuration: ``Always``)
     Always bin-pack parameters.
 
   * ``BPS_Never`` (in configuration: ``Never``)
     Never bin-pack parameters.
 
 
 
-**ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _ObjCBlockIndentWidth:
+
+**ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCBlockIndentWidth>`
   The number of characters to use for indentation of ObjC blocks.
 
   .. code-block:: objc
 
      ObjCBlockIndentWidth: 4
 
      [operation setCompletionBlock:^{
          [self onOperationDone];
      }];
 
-**ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11`
+.. _ObjCBreakBeforeNestedBlockParam:
+
+**ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <ObjCBreakBeforeNestedBlockParam>`
   Break parameters list into lines when there is nested block
   parameters in a function call.
 
   .. code-block:: c++
 
     false:
      - (void)_aMethod
      {
          [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
          *u, NSNumber *v) {
              u = c;
          }]
      }
      true:
      - (void)_aMethod
      {
         [self.test1 t:self
                      w:self
             callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
                  u = c;
              }]
      }
 
-**ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _ObjCSpaceAfterProperty:
+
+**ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceAfterProperty>`
   Add a space after ``@property`` in Objective-C, i.e. use
   ``@property (readonly)`` instead of ``@property(readonly)``.
 
-**ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _ObjCSpaceBeforeProtocolList:
+
+**ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceBeforeProtocolList>`
   Add a space in front of an Objective-C protocol list, i.e. use
   ``Foo <Protocol>`` instead of ``Foo<Protocol>``.
 
-**PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13`
+.. _PPIndentWidth:
+
+**PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13` :ref:`¶ <PPIndentWidth>`
   The number of columns to use for indentation of preprocessor statements.
   When set to -1 (default) ``IndentWidth`` is used also for preprocessor
   statements.
 
   .. code-block:: c++
 
      PPIndentWidth: 1
 
      #ifdef __linux__
      # define FOO
      #else
      # define BAR
      #endif
 
-**PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14`
+.. _PackConstructorInitializers:
+
+**PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14` :ref:`¶ <PackConstructorInitializers>`
   The pack constructor initializers style to use.
 
   Possible values:
 
   * ``PCIS_Never`` (in configuration: ``Never``)
     Always put each constructor initializer on its own line.
 
     .. code-block:: c++
.. code-block:: c++
 
        Constructor()
            : aaaaaaaaaaaaaaaaaaaa(),
              bbbbbbbbbbbbbbbbbbbb(),
              cccccccccccccccccccc()
 
 
 
-**PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5`
+.. _PenaltyBreakAssignment:
+
+**PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5` :ref:`¶ <PenaltyBreakAssignment>`
   The penalty for breaking around an assignment operator.
 
-**PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyBreakBeforeFirstCallParameter:
+
+**PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakBeforeFirstCallParameter>`
   The penalty for breaking a function call after ``call(``.
 
-**PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyBreakComment:
+
+**PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakComment>`
   The penalty for each line break introduced inside a comment.
 
-**PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyBreakFirstLessLess:
+
+**PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakFirstLessLess>`
   The penalty for breaking before the first ``<<``.
 
-**PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14`
+.. _PenaltyBreakOpenParenthesis:
+
+**PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14` :ref:`¶ <PenaltyBreakOpenParenthesis>`
   The penalty for breaking after ``(``.
 
-**PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyBreakString:
+
+**PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakString>`
   The penalty for each line break introduced inside a string literal.
 
-**PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7`
+.. _PenaltyBreakTemplateDeclaration:
+
+**PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7` :ref:`¶ <PenaltyBreakTemplateDeclaration>`
   The penalty for breaking after template declaration.
 
-**PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyExcessCharacter:
+
+**PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyExcessCharacter>`
   The penalty for each character outside of the column limit.
 
-**PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12`
+.. _PenaltyIndentedWhitespace:
+
+**PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12` :ref:`¶ <PenaltyIndentedWhitespace>`
   Penalty for each character of whitespace indentation
   (counted relative to leading non-whitespace column).
 
-**PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _PenaltyReturnTypeOnItsOwnLine:
+
+**PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyReturnTypeOnItsOwnLine>`
   Penalty for putting the return type of a function onto its own line.
 
-**PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7`
+.. _PointerAlignment:
+
+**PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <PointerAlignment>`
   Pointer and reference alignment style.
 
   Possible values:
 
   * ``PAS_Left`` (in configuration: ``Left``)
     Align pointer to the left.
 
     .. code-block:: c++
* ``PAS_Middle`` (in configuration: ``Middle``)
     Align pointer in the middle.
 
     .. code-block:: c++
 
       int * a;
 
 
 
-**QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14`
+.. _QualifierAlignment:
+
+**QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierAlignment>`
   Different ways to arrange specifiers and qualifiers (e.g. const/volatile).
 
   .. warning:: 
 
    Setting ``QualifierAlignment``  to something other than `Leave`, COULD
    lead to incorrect code formatting due to incorrect decisions made due to
    clang-formats lack of complete semantic information.
    As such extra care should be taken to review code changes made by the use
* ``QAS_Custom`` (in configuration: ``Custom``)
     .. code-block:: c++
 
 
        int const a;
        int const *a;
 
 
 
-**QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14`
+.. _QualifierOrder:
+
+**QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierOrder>`
   The order in which the qualifiers appear.
   Order is an array that can contain any of the following:
 
     * const
     * inline
     * static
     * friend
     * constexpr
     * volatile
     * restrict
     * type
 
   Note: it MUST contain 'type'.
   Items to the left of 'type' will be placed to the left of the type and
   aligned in the order supplied. Items to the right of 'type' will be placed
   to the right of the type and aligned in the order supplied.
 
 
   .. code-block:: yaml
 
     QualifierOrder: ['inline', 'static', 'type', 'const', 'volatile' ]
 
-**RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6`
+.. _RawStringFormats:
+
+**RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6` :ref:`¶ <RawStringFormats>`
   Defines hints for detecting supported languages code blocks in raw
   strings.
 
   A raw string with a matching delimiter or a matching enclosing function
   name will be reformatted assuming the specified language based on the
   style for that language defined in the .clang-format file. If no style has
   been defined in the .clang-format file for the specific language, a
   predefined style given by 'BasedOnStyle' is used. If 'BasedOnStyle' is not
RawStringFormats:
           BasedOnStyle: google
       - Language: Cpp
           Delimiters:
             - 'cc'
             - 'cpp'
           BasedOnStyle: llvm
           CanonicalDelimiter: 'cc'
 
-**ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13`
+.. _ReferenceAlignment:
+
+**ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <ReferenceAlignment>`
   Reference alignment style (overrides ``PointerAlignment`` for
   references).
 
   Possible values:
 
   * ``RAS_Pointer`` (in configuration: ``Pointer``)
     Align reference like ``PointerAlignment``.
 
* ``RAS_Middle`` (in configuration: ``Middle``)
     Align reference in the middle.
 
     .. code-block:: c++
 
       int & a;
 
 
 
-**ReflowComments** (``Boolean``) :versionbadge:`clang-format 3.8`
+.. _ReflowComments:
+
+**ReflowComments** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <ReflowComments>`
   If ``true``, clang-format will attempt to re-flow comments. That is it
   will touch a comment and *reflow* long comments into new lines, trying to
   obey the ``ColumnLimit``.
 
   .. code-block:: c++
 
      false:
      // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
      /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
 
      true:
      // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
      // information
      /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
       * information */
 
-**RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14`
+.. _RemoveBracesLLVM:
+
+**RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ <RemoveBracesLLVM>`
   Remove optional braces of control statements (``if``, ``else``, ``for``,
   and ``while``) in C++ according to the LLVM coding style.
 
   .. warning:: 
 
    This option will be renamed and expanded to support other styles.
 
   .. warning:: 
.. code-block:: c++
     } else {                                   else if (c)
       if (c) {                                   d();
         d();                                   else
       } else {                                   e();
         e();
       }
     }
 
-**RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16`
+.. _RemoveSemicolon:
+
+**RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <RemoveSemicolon>`
   Remove semicolons after the closing brace of a non-empty function.
 
   .. warning:: 
 
    Setting this option to `true` could lead to incorrect code formatting due
    to clang-format's lack of complete semantic information. As such, extra
    care should be taken to review code changes made by this option.
 
   .. code-block:: c++
 
     false:                                     true:
 
     int max(int a, int b) {                    int max(int a, int b) {
       return a > b ? a : b;                      return a > b ? a : b;
     };                                         }
 
-**RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15`
+.. _RequiresClausePosition:
+
+**RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15` :ref:`¶ <RequiresClausePosition>`
   The position of the ``requires`` clause.
 
   Possible values:
 
   * ``RCPS_OwnLine`` (in configuration: ``OwnLine``)
     Always put the ``requires`` clause on its own line.
 
     .. code-block:: c++
.. code-block:: c++
       void bar(LongName ln) {
 
       template <typename LongName>
       void bar(LongName ln)
           requires C<LongName> {
 
 
 
-**RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16`
+.. _RequiresExpressionIndentation:
+
+**RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16` :ref:`¶ <RequiresExpressionIndentation>`
   The indentation used for requires expression bodies.
 
   Possible values:
 
   * ``REI_OuterScope`` (in configuration: ``OuterScope``)
     Align requires expression body relative to the indentation level of the
     outer scope the requires expression resides in.
     This is the default.
.. code-block:: c++
 
        template <typename T>
        concept C = requires(T t) {
                      ...
                    }
 
 
 
-**SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14`
+.. _SeparateDefinitionBlocks:
+
+**SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ <SeparateDefinitionBlocks>`
   Specifies the use of empty lines to separate definition blocks, including
   classes, structs, enums, and functions.
 
   .. code-block:: c++
 
      Never                  v.s.     Always
      #include <cstring>              #include <cstring>
      struct Foo {
**SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ <SeparateDefinitionBlocks>`
   * ``SDS_Always`` (in configuration: ``Always``)
     Insert an empty line between definition blocks.
 
   * ``SDS_Never`` (in configuration: ``Never``)
     Remove any empty line between definition blocks.
 
 
 
-**ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13`
+.. _ShortNamespaceLines:
+
+**ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13` :ref:`¶ <ShortNamespaceLines>`
   The maximal number of unwrapped lines that a short namespace spans.
   Defaults to 1.
 
   This determines the maximum length of short namespaces by counting
   unwrapped lines (i.e. containing neither opening nor closing
   namespace brace) and makes "FixNamespaceComments" omit adding
   end comments for those.
 
   .. code-block:: c++
 
      ShortNamespaceLines: 1     vs.     ShortNamespaceLines: 0
      namespace a {                      namespace a {
        int foo;                           int foo;
      }                                  } // namespace a
 
      ShortNamespaceLines: 1     vs.     ShortNamespaceLines: 0
      namespace b {                      namespace b {
        int foo;                           int foo;
        int bar;                           int bar;
      } // namespace b                   } // namespace b
 
-**SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8`
+.. _SortIncludes:
+
+**SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8` :ref:`¶ <SortIncludes>`
   Controls if and how clang-format will sort ``#includes``.
   If ``Never``, includes are never sorted.
   If ``CaseInsensitive``, includes are sorted in an ASCIIbetical or case
   insensitive fashion.
   If ``CaseSensitive``, includes are sorted in an alphabetical or case
   sensitive fashion.
 
   Possible values:
.. code-block:: c++
        #include "A/B.h"
        #include "A/b.h"
        #include "a/b.h"
        #include "B/A.h"
        #include "B/a.h"
 
 
 
-**SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12`
+.. _SortJavaStaticImport:
+
+**SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12` :ref:`¶ <SortJavaStaticImport>`
   When sorting Java imports, by default static imports are placed before
   non-static imports. If ``JavaStaticImportAfterImport`` is ``After``,
   static imports are placed after non-static imports.
 
   Possible values:
 
   * ``SJSIO_Before`` (in configuration: ``Before``)
     Static imports are placed before non-static imports.
* ``SJSIO_After`` (in configuration: ``After``)
     .. code-block:: java
 
       import org.example.ClassA;
 
       import static org.example.function1;
 
 
 
-**SortUsingDeclarations** (``Boolean``) :versionbadge:`clang-format 5`
+.. _SortUsingDeclarations:
+
+**SortUsingDeclarations** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <SortUsingDeclarations>`
   If ``true``, clang-format will sort using declarations.
 
   The order of using declarations is defined as follows:
   Split the strings by "::" and discard any initial empty strings. The last
   element of each list is a non-namespace name; all others are namespace
   names. Sort the lists of names lexicographically, where the sort order of
   individual names is that all non-namespace names come before all namespace
   names, and within those groups, names are in case-insensitive
   lexicographic order.
 
   .. code-block:: c++
 
      false:                                 true:
      using std::cout;               vs.     using std::cin;
      using std::cin;                        using std::cout;
 
-**SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5`
+.. _SpaceAfterCStyleCast:
+
+**SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceAfterCStyleCast>`
   If ``true``, a space is inserted after C style casts.
 
   .. code-block:: c++
 
      true:                                  false:
      (int) i;                       vs.     (int)i;
 
-**SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9`
+.. _SpaceAfterLogicalNot:
+
+**SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <SpaceAfterLogicalNot>`
   If ``true``, a space is inserted after the logical not operator (``!``).
 
   .. code-block:: c++
 
      true:                                  false:
      ! someExpression();            vs.     !someExpression();
 
-**SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4`
+.. _SpaceAfterTemplateKeyword:
+
+**SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4` :ref:`¶ <SpaceAfterTemplateKeyword>`
   If ``true``, a space will be inserted after the 'template' keyword.
 
   .. code-block:: c++
 
      true:                                  false:
      template <int> void foo();     vs.     template<int> void foo();
 
-**SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12`
+.. _SpaceAroundPointerQualifiers:
+
+**SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceAroundPointerQualifiers>`
   Defines in which cases to put a space before or after pointer qualifiers
 
   Possible values:
 
   * ``SAPQ_Default`` (in configuration: ``Default``)
     Don't ensure spaces around pointer qualifiers and use PointerAlignment
     instead.
 
* ``SAPQ_Both`` (in configuration: ``Both``)
 
     .. code-block:: c++
 
        PointerAlignment: Left                 PointerAlignment: Right
        void* const * x = NULL;         vs.     void * const *x = NULL;
 
 
 
-**SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpaceBeforeAssignmentOperators:
+
+**SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceBeforeAssignmentOperators>`
   If ``false``, spaces will be removed before assignment operators.
 
   .. code-block:: c++
 
      true:                                  false:
      int a = 5;                     vs.     int a= 5;
      a += 42;                               a+= 42;
 
-**SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12`
+.. _SpaceBeforeCaseColon:
+
+**SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceBeforeCaseColon>`
   If ``false``, spaces will be removed before case colon.
 
   .. code-block:: c++
 
     true:                                   false
     switch (x) {                    vs.     switch (x) {
       case 1 : break;                         case 1: break;
     }                                       }
 
-**SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7`
+.. _SpaceBeforeCpp11BracedList:
+
+**SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCpp11BracedList>`
   If ``true``, a space will be inserted before a C++11 braced list
   used to initialize an object (after the preceding identifier or type).
 
   .. code-block:: c++
 
      true:                                  false:
      Foo foo { bar };               vs.     Foo foo{ bar };
      Foo {};                                Foo{};
      vector<int> { 1, 2, 3 };               vector<int>{ 1, 2, 3 };
      new int[3] { 1, 2, 3 };                new int[3]{ 1, 2, 3 };
 
-**SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7`
+.. _SpaceBeforeCtorInitializerColon:
+
+**SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCtorInitializerColon>`
   If ``false``, spaces will be removed before constructor initializer
   colon.
 
   .. code-block:: c++
 
      true:                                  false:
      Foo::Foo() : a(a) {}                   Foo::Foo(): a(a) {}
 
-**SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7`
+.. _SpaceBeforeInheritanceColon:
+
+**SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeInheritanceColon>`
   If ``false``, spaces will be removed before inheritance colon.
 
   .. code-block:: c++
 
      true:                                  false:
      class Foo : Bar {}             vs.     class Foo: Bar {}
 
-**SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5`
+.. _SpaceBeforeParens:
+
+**SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceBeforeParens>`
   Defines in which cases to put a space before opening parentheses.
 
   Possible values:
 
   * ``SBPO_Never`` (in configuration: ``Never``)
     Never put a space before opening parentheses.
 
     .. code-block:: c++
.. code-block:: c++
        }
 
   * ``SBPO_Custom`` (in configuration: ``Custom``)
     Configure each individual space before parentheses in
     `SpaceBeforeParensOptions`.
 
 
 
-**SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14`
+.. _SpaceBeforeParensOptions:
+
+**SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14` :ref:`¶ <SpaceBeforeParensOptions>`
   Control of individual space before parentheses.
 
   If ``SpaceBeforeParens`` is set to ``Custom``, use this to specify
   how each individual space before parentheses case should be handled.
   Otherwise, this is ignored.
 
   .. code-block:: yaml
 
* ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening parentheses only if the
 
     .. code-block:: c++
 
        true:                                  false:
        void f (int a);                 vs.    void f();
        f (a);                                 f();
 
 
-**SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7`
+.. _SpaceBeforeRangeBasedForLoopColon:
+
+**SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeRangeBasedForLoopColon>`
   If ``false``, spaces will be removed before range-based for loop
   colon.
 
   .. code-block:: c++
 
      true:                                  false:
      for (auto v : values) {}       vs.     for(auto v: values) {}
 
-**SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10`
+.. _SpaceBeforeSquareBrackets:
+
+**SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceBeforeSquareBrackets>`
   If ``true``, spaces will be before  ``[``.
   Lambdas will not be affected. Only the first ``[`` will get a space added.
 
   .. code-block:: c++
 
      true:                                  false:
      int a [5];                    vs.      int a[5];
      int a [5][5];                 vs.      int a[5][5];
 
-**SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10`
+.. _SpaceInEmptyBlock:
+
+**SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceInEmptyBlock>`
   If ``true``, spaces will be inserted into ``{}``.
 
   .. code-block:: c++
 
      true:                                false:
      void f() { }                   vs.   void f() {}
      while (true) { }                     while (true) {}
 
-**SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpaceInEmptyParentheses:
+
+**SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceInEmptyParentheses>`
   If ``true``, spaces may be inserted into ``()``.
 
   .. code-block:: c++
 
      true:                                false:
      void f( ) {                    vs.   void f() {
        int x[] = {foo( ), bar( )};          int x[] = {foo(), bar()};
        if (true) {                          if (true) {
          f( );                                f();
        }                                    }
      }                                    }
 
-**SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _SpacesBeforeTrailingComments:
+
+**SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesBeforeTrailingComments>`
   The number of spaces before trailing line comments
   (``//`` - comments).
 
   This does not affect trailing block comments (``/*`` - comments) as
   those commonly have different usage patterns and a number of special
   cases.
 
   .. code-block:: c++
 
      SpacesBeforeTrailingComments: 3
      void f() {
        if (true) {   // foo1
          f();        // bar
        }             // foo
      }
 
-**SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4`
+.. _SpacesInAngles:
+
+**SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <SpacesInAngles>`
   The SpacesInAnglesStyle to use for template argument lists.
 
   Possible values:
 
   * ``SIAS_Never`` (in configuration: ``Never``)
     Remove spaces after ``<`` and before ``>``.
 
     .. code-block:: c++
.. code-block:: c++
        std::function< void(int) > fct;
 
   * ``SIAS_Leave`` (in configuration: ``Leave``)
     Keep a single space after ``<`` and before ``>`` if any spaces were
     present. Option ``Standard: Cpp03`` takes precedence.
 
 
 
-**SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpacesInCStyleCastParentheses:
+
+**SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInCStyleCastParentheses>`
   If ``true``, spaces may be inserted into C style casts.
 
   .. code-block:: c++
 
      true:                                  false:
      x = ( int32 )y                 vs.     x = (int32)y
 
-**SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10`
+.. _SpacesInConditionalStatement:
+
+**SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpacesInConditionalStatement>`
   If ``true``, spaces will be inserted around if/for/switch/while
   conditions.
 
   .. code-block:: c++
 
      true:                                  false:
      if ( a )  { ... }              vs.     if (a) { ... }
      while ( i < 5 )  { ... }               while (i < 5) { ... }
 
-**SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpacesInContainerLiterals:
+
+**SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInContainerLiterals>`
   If ``true``, spaces are inserted inside container literals (e.g.
   ObjC and Javascript array and dict literals).
 
   .. code-block:: js
 
      true:                                  false:
      var arr = [ 1, 2, 3 ];         vs.     var arr = [1, 2, 3];
      f({a : 1, b : 2, c : 3});              f({a: 1, b: 2, c: 3});
 
-**SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13`
+.. _SpacesInLineCommentPrefix:
+
+**SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ <SpacesInLineCommentPrefix>`
   How many spaces are allowed at the start of a line comment. To disable the
   maximum set it to ``-1``, apart from that the maximum takes precedence
   over the minimum.
 
   .. code-block:: c++
 
     Minimum = 1
     Maximum = -1
**SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ <SpacesInLineCommentPrefix>`
 
   Control of spaces within a single line comment.
 
   * ``unsigned Minimum`` The minimum number of spaces at the start of the comment.
 
   * ``unsigned Maximum`` The maximum number of spaces at the start of the comment.
 
 
-**SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpacesInParentheses:
+
+**SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInParentheses>`
   If ``true``, spaces will be inserted after ``(`` and before ``)``.
 
   .. code-block:: c++
 
      true:                                  false:
      t f( Deleted & ) & = delete;   vs.     t f(Deleted &) & = delete;
 
-**SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7`
+.. _SpacesInSquareBrackets:
+
+**SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInSquareBrackets>`
   If ``true``, spaces will be inserted after ``[`` and before ``]``.
   Lambdas without arguments or unspecified size array declarations will not
   be affected.
 
   .. code-block:: c++
 
      true:                                  false:
      int a[ 5 ];                    vs.     int a[5];
      std::unique_ptr<int[]> foo() {} // Won't be affected
 
-**Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7`
+.. _Standard:
+
+**Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7` :ref:`¶ <Standard>`
   Parse and format C++ constructs compatible with this standard.
 
   .. code-block:: c++
 
      c++03:                                 latest:
      vector<set<int> > x;           vs.     vector<set<int>> x;
 
   Possible values:
* ``LS_Latest`` (in configuration: ``Latest``)
     Parse and format using the latest supported language version.
     ``Cpp11`` is a deprecated alias for ``Latest``
 
   * ``LS_Auto`` (in configuration: ``Auto``)
     Automatic detection based on the input.
 
 
 
-**StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12`
+.. _StatementAttributeLikeMacros:
+
+**StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <StatementAttributeLikeMacros>`
   Macros which are ignored in front of a statement, as if they were an
   attribute. So that they are not parsed as identifier, for example for Qts
   emit.
 
   .. code-block:: c++
 
     AlignConsecutiveDeclarations: true
     StatementAttributeLikeMacros: []
     unsigned char data = 'x';
     emit          signal(data); // This is parsed as variable declaration.
 
     AlignConsecutiveDeclarations: true
     StatementAttributeLikeMacros: [emit]
     unsigned char data = 'x';
     emit signal(data); // Now it's fine again.
 
-**StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8`
+.. _StatementMacros:
+
+**StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <StatementMacros>`
   A vector of macros that should be interpreted as complete
   statements.
 
   Typical macros are expressions, and require a semi-colon to be
   added; sometimes this is not the case, and this allows to make
   clang-format aware of such cases.
 
   For example: Q_UNUSED
 
-**TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7`
+.. _TabWidth:
+
+**TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <TabWidth>`
   The number of columns used for tab stops.
 
-**TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9`
+.. _TypenameMacros:
+
+**TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <TypenameMacros>`
   A vector of macros that should be interpreted as type declarations
   instead of as function calls.
 
   These are expected to be macros of the form:
 
   .. code-block:: c++
 
     STACK_OF(...)
 
   In the .clang-format configuration file, this can be configured like:
 
   .. code-block:: yaml
 
     TypenameMacros: ['STACK_OF', 'LIST']
 
   For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
 
-**UseCRLF** (``Boolean``) :versionbadge:`clang-format 10`
+.. _UseCRLF:
+
+**UseCRLF** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <UseCRLF>`
   Use ``\r\n`` instead of ``\n`` for line breaks.
   Also used as fallback if ``DeriveLineEnding`` is true.
 
-**UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7`
+.. _UseTab:
+
+**UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <UseTab>`
   The way to use tab characters in the resulting file.
 
   Possible values:
 
   * ``UT_Never`` (in configuration: ``Never``)
     Never use tab.
 
   * ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
     Use tabs only for indentation.
 
   * ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
     Fill all leading whitespace with tabs, and use spaces for alignment that
     appears within a line (e.g. consecutive assignments and declarations).
 
   * ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
     Use tabs for line continuation and indentation, and spaces for
     alignment.
 
   * ``UT_Always`` (in configuration: ``Always``)
     Use tabs whenever we need to fill whitespace that spans at least from
     one tab stop to the next one.
 
 
 
-**WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11`
+.. _WhitespaceSensitiveMacros:
+
+**WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11` :ref:`¶ <WhitespaceSensitiveMacros>`
   A vector of macros which are whitespace-sensitive and should not
   be touched.
 
   These are expected to be macros of the form:
 
   .. code-block:: c++
 
     STRINGIZE(...)

clang/docs/tools/dump_format_style.py

def __init__(self, name, opt_type, comment, version):
     self.name = name
     self.type = opt_type
     self.comment = comment.strip()
     self.enum = None
     self.nested_struct = None
     self.version = version
 
   def __str__(self):
+    s = ".. _%s:\n\n**%s** (``%s``) " % (self.name, self.name, to_yaml_type(self.type))
     if self.version:
-      s = '**%s** (``%s``) :versionbadge:`clang-format %s`\n%s' % (self.name, to_yaml_type(self.type), self.version,
-                                 doxygen2rst(indent(self.comment, 2)))
-    else:
-      s = '**%s** (``%s``)\n%s' % (self.name, to_yaml_type(self.type),
-                                 doxygen2rst(indent(self.comment, 2)))
+      s += ':versionbadge:`clang-format %s` ' % self.version
+    s += ':ref:`¶ <%s>`\n%s' % (self.name, doxygen2rst(indent(self.comment, 2)))
     if self.enum and self.enum.values:
       s += indent('\n\nPossible values:\n\n%s\n' % self.enum, 2)
     if self.nested_struct:
       s += indent('\n\nNested configuration flags:\n\n%s\n' %self.nested_struct,
                   2)
     return s
 
 class NestedStruct(object):