[llvm-branch-commits] [clang-tools-extra] [clang-tidy][docs] Rewrite readability check docs to Markdown [3/5] (PR #221534)
Zeyi Xu via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Sat Sep 5 23:52:56 PDT 2026
https://github.com/zeyi2 created https://github.com/llvm/llvm-project/pull/221534
<sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
>From 76aa59d1556b326596802d9bb63af02b32508c46 Mon Sep 17 00:00:00 2001
From: Zeyi Xu <mitchell.xu2 at gmail.com>
Date: Sun, 6 Sep 2026 14:51:22 +0800
Subject: [PATCH] [clang-tidy][docs] Rewrite readability check docs to Markdown
[3/5]
---
.../readability/misleading-indentation.md | 40 ++--
.../checks/readability/named-parameter.md | 109 +++++----
.../checks/readability/non-const-parameter.md | 74 +++---
.../readability/operators-representation.md | 99 ++++----
.../checks/readability/qualified-auto.md | 223 +++++++++---------
.../redundant-access-specifiers.md | 75 +++---
.../checks/readability/redundant-casting.md | 62 +++--
.../readability/redundant-control-flow.md | 66 +++---
.../readability/redundant-declaration.md | 37 ++-
.../readability/redundant-inline-specifier.md | 39 ++-
10 files changed, 403 insertions(+), 421 deletions(-)
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/misleading-indentation.md b/clang-tools-extra/docs/clang-tidy/checks/readability/misleading-indentation.md
index cac55dd8c22b9..8a91c0a094f93 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/misleading-indentation.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/misleading-indentation.md
@@ -1,39 +1,37 @@
-.. title:: clang-tidy - readability-misleading-indentation
+```{title} clang-tidy - readability-misleading-indentation
+```
-readability-misleading-indentation
-==================================
+# readability-misleading-indentation
Correct indentation helps to understand code. Mismatch of the syntactical
structure and the indentation of the code may hide serious problems.
Missing braces can also make it significantly harder to read the code,
therefore it is important to use braces.
-The way to avoid dangling else is to always check that an ``else`` belongs
-to the ``if`` that begins in the same column.
+The way to avoid dangling else is to always check that an `else` belongs
+to the `if` that begins in the same column.
-You can omit braces when your inner part of e.g. an ``if`` statement has only
+You can omit braces when your inner part of e.g. an `if` statement has only
one statement in it. Although in that case you should begin the next statement
-in the same column with the ``if``.
+in the same column with the `if`.
Examples:
-.. code-block:: c++
-
- // Dangling else:
- if (cond1)
- if (cond2)
- foo1();
- else
- foo2(); // Wrong indentation: else belongs to if(cond2) statement.
-
- // Missing braces:
- if (cond1)
+```c++
+// Dangling else:
+if (cond1)
+ if (cond2)
foo1();
- foo2(); // Not guarded by if(cond1).
+else
+ foo2(); // Wrong indentation: else belongs to if(cond2) statement.
+// Missing braces:
+if (cond1)
+ foo1();
+ foo2(); // Not guarded by if(cond1).
+```
-Limitations
------------
+## Limitations
Note that this check only works as expected when the tabs or spaces are used
consistently and not mixed.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.md b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.md
index 2ab19173055b1..8ca01b6932eab 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/named-parameter.md
@@ -1,73 +1,72 @@
-.. title:: clang-tidy - readability-named-parameter
+```{title} clang-tidy - readability-named-parameter
+```
-readability-named-parameter
-===========================
+# readability-named-parameter
Find functions with unnamed arguments.
The check implements the following rule originating in the Google C++ Style
Guide:
-https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions
+<https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions>
All parameters should have the same name in both the function declaration and
definition. If a parameter is not utilized, its name can be commented out in a
function definition.
-.. code-block:: c++
+```c++
+int doingSomething(int a, int b, int c);
- int doingSomething(int a, int b, int c);
-
- int doingSomething(int a, int b, int /*c*/) {
- // Ok: the third param is not used
- return a + b;
- }
+int doingSomething(int a, int b, int /*c*/) {
+ // Ok: the third param is not used
+ return a + b;
+}
+```
Corresponding cpplint.py check name: `readability/function`.
The check ignores parameters whose types are standard tag types (e.g.
-``std::in_place_t``, ``std::allocator_arg_t``, ``std::nothrow_t``,
+`std::in_place_t`, `std::allocator_arg_t`, `std::nothrow_t`,
iterator tags, lock tags, etc.). The set of ignored types can be customized
-with the :option:`IgnoredTypes` option.
-
-Options
--------
-
-.. option:: InsertPlainNamesInForwardDecls
-
- If set to `true`, the check will insert parameter names without comments for
- forward declarations only. Otherwise, the check will insert parameter names
- as comments (e.g., ``/*param*/``). Default is `false`.
-
-.. option:: IgnoredTypes
-
- A semicolon-separated list of fully-qualified type names whose parameters
- do not need to be named (for example, tag dispatch types, iterator tags,
- etc.). Defaults to the standard tag types:
-
- .. code-block:: text
-
- std::adopt_lock_t
- std::allocator_arg_t
- std::bidirectional_iterator_tag
- std::contiguous_iterator_tag
- std::default_sentinel_t
- std::defer_lock_t
- std::destroying_delete_t
- std::forward_iterator_tag
- std::from_range_t
- std::in_place_index_t
- std::in_place_t
- std::in_place_type_t
- std::input_iterator_tag
- std::nothrow_t
- std::nostopstate_t
- std::nullopt_t
- std::output_iterator_tag
- std::piecewise_construct_t
- std::random_access_iterator_tag
- std::sorted_equivalent_t
- std::sorted_unique_t
- std::try_to_lock_t
- std::unexpect_t
- std::unreachable_sentinel_t
+with the [`IgnoredTypes`](#readability-named-parameter-ignored-types) option.
+
+## Options
+
+```{option} InsertPlainNamesInForwardDecls
+When `true`, the check will insert parameter names without comments for
+forward declarations only. Otherwise, the check will insert parameter names
+as comments (e.g., `/*param*/`). Default is `false`.
+```
+
+(readability-named-parameter-ignored-types)=
+
+```{option} IgnoredTypes
+A semicolon-separated list of fully-qualified type names whose parameters
+do not need to be named (for example, tag dispatch types, iterator tags,
+etc.). The following standard tag types are ignored by default:
+
+- `std::adopt_lock_t`
+- `std::allocator_arg_t`
+- `std::bidirectional_iterator_tag`
+- `std::contiguous_iterator_tag`
+- `std::default_sentinel_t`
+- `std::defer_lock_t`
+- `std::destroying_delete_t`
+- `std::forward_iterator_tag`
+- `std::from_range_t`
+- `std::in_place_index_t`
+- `std::in_place_t`
+- `std::in_place_type_t`
+- `std::input_iterator_tag`
+- `std::nothrow_t`
+- `std::nostopstate_t`
+- `std::nullopt_t`
+- `std::output_iterator_tag`
+- `std::piecewise_construct_t`
+- `std::random_access_iterator_tag`
+- `std::sorted_equivalent_t`
+- `std::sorted_unique_t`
+- `std::try_to_lock_t`
+- `std::unexpect_t`
+- `std::unreachable_sentinel_t`
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/non-const-parameter.md b/clang-tools-extra/docs/clang-tidy/checks/readability/non-const-parameter.md
index 9e71636b1ffad..2788a482b27e2 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/non-const-parameter.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/non-const-parameter.md
@@ -1,51 +1,49 @@
-.. title:: clang-tidy - readability-non-const-parameter
+```{title} clang-tidy - readability-non-const-parameter
+```
-readability-non-const-parameter
-===============================
+# readability-non-const-parameter
The check finds function parameters of a pointer type that could be changed to
point to a constant type instead.
-When ``const`` is used properly, many mistakes can be avoided. Advantages when
-using ``const`` properly:
+When `const` is used properly, many mistakes can be avoided. Advantages when
+using `const` properly:
- prevent unintentional modification of data;
-
- get additional warnings such as using uninitialized data;
-
- make it easier for developers to see possible side effects.
This check is not strict about constness, it only warns when the constness will
make the function interface safer.
-.. code-block:: c++
-
- // warning here; the declaration "const char *p" would make the function
- // interface safer.
- char f1(char *p) {
- return *p;
- }
-
- // no warning; the declaration could be more const "const int * const p" but
- // that does not make the function interface safer.
- int f2(const int *p) {
- return *p;
- }
-
- // no warning; making x const does not make the function interface safer
- int f3(int x) {
- return x;
- }
-
- // no warning; Technically, *p can be const ("const struct S *p"). But making
- // *p const could be misleading. People might think that it's safe to pass
- // const data to this function.
- struct S { int *a; int *b; };
- int f3(struct S *p) {
- *(p->a) = 0;
- }
-
- // no warning; p is referenced by an lvalue.
- void f4(int *p) {
- int &x = *p;
- }
+```c++
+// warning here; the declaration "const char *p" would make the function
+// interface safer.
+char f1(char *p) {
+ return *p;
+}
+
+// no warning; the declaration could be more const "const int * const p" but
+// that does not make the function interface safer.
+int f2(const int *p) {
+ return *p;
+}
+
+// no warning; making x const does not make the function interface safer
+int f3(int x) {
+ return x;
+}
+
+// no warning; Technically, *p can be const ("const struct S *p"). But making
+// *p const could be misleading. People might think that it's safe to pass
+// const data to this function.
+struct S { int *a; int *b; };
+int f3(struct S *p) {
+ *(p->a) = 0;
+}
+
+// no warning; p is referenced by an lvalue.
+void f4(int *p) {
+ int &x = *p;
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/operators-representation.md b/clang-tools-extra/docs/clang-tidy/checks/readability/operators-representation.md
index 70cf75b72ff78..6112a26621222 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/operators-representation.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/operators-representation.md
@@ -1,63 +1,60 @@
-.. title:: clang-tidy - readability-operators-representation
+```{title} clang-tidy - readability-operators-representation
+```
-readability-operators-representation
-====================================
+# readability-operators-representation
Enforces consistent token representation for invoked binary, unary and
overloaded operators in C++ code. The check supports both traditional and
-alternative representations of operators, such as ``&&`` and ``and``, ``||``
-and ``or``, and so on.
+alternative representations of operators, such as `&&` and `and`, `||`
+and `or`, and so on.
In the realm of C++ programming, developers have the option to choose between
two distinct representations for operators: traditional token representation
and alternative token representation. Traditional tokens utilize symbols,
-such as ``&&``, ``||``, and ``!``, while alternative tokens employ more
-descriptive words like ``and``, ``or``, and ``not``.
+such as `&&`, `||`, and `!`, while alternative tokens employ more
+descriptive words like `and`, `or`, and `not`.
In the following mapping table, a comprehensive list of traditional and
alternative tokens, along with their corresponding representations,
is presented:
-.. table:: Token Representation Mapping Table
- :widths: auto
+```{table} Token Representation Mapping Table
+:widths: auto
- =========== ===========
- Traditional Alternative
- =========== ===========
- ``&&`` ``and``
- ``&=`` ``and_eq``
- ``&`` ``bitand``
- ``|`` ``bitor``
- ``~`` ``compl``
- ``!`` ``not``
- ``!=`` ``not_eq``
- ``||`` ``or``
- ``|=`` ``or_eq``
- ``^`` ``xor``
- ``^=`` ``xor_eq``
- =========== ===========
+| Traditional | Alternative |
+| ----------- | ----------- |
+| `&&` | `and` |
+| `&=` | `and_eq` |
+| `&` | `bitand` |
+| `\|` | `bitor` |
+| `~` | `compl` |
+| `!` | `not` |
+| `!=` | `not_eq` |
+| `\|\|` | `or` |
+| `\|=` | `or_eq` |
+| `^` | `xor` |
+| `^=` | `xor_eq` |
+```
-Example
--------
+## Example
-.. code-block:: c++
+```c++
+// Traditional Token Representation:
- // Traditional Token Representation:
+if (!a||!b)
+{
+ // do something
+}
- if (!a||!b)
- {
- // do something
- }
+// Alternative Token Representation:
- // Alternative Token Representation:
+if (not a or not b)
+{
+ // do something
+}
+```
- if (not a or not b)
- {
- // do something
- }
-
-Options
--------
+## Options
Due to the distinct benefits and drawbacks of each representation, the default
configuration doesn't enforce either. Explicit configuration is needed.
@@ -74,14 +71,14 @@ representations as desired by specifying a semicolon-separated list of
both traditional and alternative tokens in the configuration,
such as `and;||;not`.
-.. option:: BinaryOperators
-
- This option allows you to specify a semicolon-separated list of binary
- operators for which you want to enforce specific token representation.
- The default value is empty string.
-
-.. option:: OverloadedOperators
-
- This option allows you to specify a semicolon-separated list of overloaded
- operators for which you want to enforce specific token representation.
- The default value is empty string.
+```{option} BinaryOperators
+This option allows you to specify a semicolon-separated list of binary
+operators for which you want to enforce specific token representation.
+Default is empty string.
+```
+
+```{option} OverloadedOperators
+This option allows you to specify a semicolon-separated list of overloaded
+operators for which you want to enforce specific token representation.
+Default is empty string.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/qualified-auto.md b/clang-tools-extra/docs/clang-tidy/checks/readability/qualified-auto.md
index d031b677d7618..a7c64a501fbad 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/qualified-auto.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/qualified-auto.md
@@ -1,141 +1,138 @@
-.. title:: clang-tidy - readability-qualified-auto
+```{title} clang-tidy - readability-qualified-auto
+```
-readability-qualified-auto
-==========================
+# readability-qualified-auto
-Adds pointer qualifications to ``auto``-typed variables that are deduced to
+Adds pointer qualifications to `auto`-typed variables that are deduced to
pointers.
-`LLVM Coding Standards <https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto>`_
-advises to make it obvious if a ``auto`` typed variable is a pointer. This
-check will transform ``auto`` to ``auto *`` when the type is deduced to be a
+[LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto)
+advises to make it obvious if a `auto` typed variable is a pointer. This
+check will transform `auto` to `auto *` when the type is deduced to be a
pointer.
-.. code-block:: c++
-
- for (auto Data : MutatablePtrContainer) {
- change(*Data);
- }
- for (auto Data : ConstantPtrContainer) {
- observe(*Data);
- }
+```c++
+for (auto Data : MutatablePtrContainer) {
+ change(*Data);
+}
+for (auto Data : ConstantPtrContainer) {
+ observe(*Data);
+}
+```
Would be transformed into:
-.. code-block:: c++
-
- for (auto *Data : MutatablePtrContainer) {
- change(*Data);
- }
- for (const auto *Data : ConstantPtrContainer) {
- observe(*Data);
- }
-
-Note ``const`` ``volatile`` qualified types will retain their ``const`` and
-``volatile`` qualifiers. Pointers to pointers will not be fully qualified.
-
-.. code-block:: c++
-
- const auto Foo = cast<int *>(Baz1);
- const auto Bar = cast<const int *>(Baz2);
- volatile auto FooBar = cast<int *>(Baz3);
- auto BarFoo = cast<int **>(Baz4);
+```c++
+for (auto *Data : MutatablePtrContainer) {
+ change(*Data);
+}
+for (const auto *Data : ConstantPtrContainer) {
+ observe(*Data);
+}
+```
+
+Note `const` `volatile` qualified types will retain their `const` and
+`volatile` qualifiers. Pointers to pointers will not be fully qualified.
+
+```c++
+const auto Foo = cast<int *>(Baz1);
+const auto Bar = cast<const int *>(Baz2);
+volatile auto FooBar = cast<int *>(Baz3);
+auto BarFoo = cast<int **>(Baz4);
+```
Would be transformed into:
-.. code-block:: c++
-
- auto *const Foo = cast<int *>(Baz1);
- const auto *const Bar = cast<const int *>(Baz2);
- auto *volatile FooBar = cast<int *>(Baz3);
- auto *BarFoo = cast<int **>(Baz4);
-
-Options
--------
-
-.. option:: AddConstToQualified
+```c++
+auto *const Foo = cast<int *>(Baz1);
+const auto *const Bar = cast<const int *>(Baz2);
+auto *volatile FooBar = cast<int *>(Baz3);
+auto *BarFoo = cast<int **>(Baz4);
+```
- When set to `true` the check will add const qualifiers variables defined as
- ``auto *`` or ``auto &`` when applicable.
- Default value is `true`.
+## Options
-.. code-block:: c++
+```{option} AddConstToQualified
+When `true`, the check will add const qualifiers to variables defined as
+`auto *` or `auto &` when applicable.
+Default is `true`.
+```
- auto Foo1 = cast<const int *>(Bar1);
- auto *Foo2 = cast<const int *>(Bar2);
- auto &Foo3 = cast<const int &>(Bar3);
+```c++
+auto Foo1 = cast<const int *>(Bar1);
+auto *Foo2 = cast<const int *>(Bar2);
+auto &Foo3 = cast<const int &>(Bar3);
+```
-If AddConstToQualified is set to `false`, it will be transformed into:
+If {option}`AddConstToQualified` is set to `false`, it will be transformed into:
-.. code-block:: c++
-
- const auto *Foo1 = cast<const int *>(Bar1);
- auto *Foo2 = cast<const int *>(Bar2);
- auto &Foo3 = cast<const int &>(Bar3);
+```c++
+const auto *Foo1 = cast<const int *>(Bar1);
+auto *Foo2 = cast<const int *>(Bar2);
+auto &Foo3 = cast<const int &>(Bar3);
+```
Otherwise it will be transformed into:
-.. code-block:: c++
-
- const auto *Foo1 = cast<const int *>(Bar1);
- const auto *Foo2 = cast<const int *>(Bar2);
- const auto &Foo3 = cast<const int &>(Bar3);
-
-Note in the LLVM alias, the default value is `false`.
-
-.. option:: AllowedTypes
-
- A semicolon-separated list of names of types to ignore when ``auto`` is
- deduced to that type or a pointer to that type. Note that this distinguishes
- type aliases from the original type, so specifying e.g. ``my_int`` will not
- suppress reports about ``int`` even if it is defined as a ``typedef`` alias
- for ``int``. Regular expressions are accepted, e.g. ``[Rr]ef(erence)?$``
- matches every type with suffix ``Ref``, ``ref``, ``Reference`` and
- ``reference``. If a name in the list contains the sequence `::` it is matched
- against the qualified type name (i.e. ``namespace::Type``), otherwise it is
- matched against only the type name (i.e. ``Type``). E.g. to suppress reports
- for ``std::array`` iterators use `std::array<.*>::(const_)?iterator` string.
- The default is an empty string.
-
-.. option:: IgnoreAliasing
-
- If set to `true` the check will use the underlying type to determine the type
- that ``auto`` is deduced to. If set to `false` the check will not look beyond
- the first type alias.
- Default value is `true`.
-
- .. code-block:: c++
-
- using IntPtr = int*;
- IntPtr foo();
-
- auto bar = foo();
-
- If :option:`IgnoreAliasing` is set to `true`, it will be transformed into:
-
- .. code-block:: c++
-
- auto *bar = foo();
-
- Otherwise no changes will occur.
-
-
-Limitations
------------
-
-When :option:`IgnoreAliasing` is set to `false`, there are cases where
+```c++
+const auto *Foo1 = cast<const int *>(Bar1);
+const auto *Foo2 = cast<const int *>(Bar2);
+const auto &Foo3 = cast<const int &>(Bar3);
+```
+
+For the `llvm-qualified-auto` alias, default is `false`.
+
+```{option} AllowedTypes
+A semicolon-separated list of names of types to ignore when `auto` is
+deduced to that type or a pointer to that type. Note that this distinguishes
+type aliases from the original type, so specifying e.g. `my_int` will not
+suppress reports about `int` even if it is defined as a `typedef` alias
+for `int`. Regular expressions are accepted, e.g. `[Rr]ef(erence)?$`
+matches every type with suffix `Ref`, `ref`, `Reference` and
+`reference`. If a name in the list contains the sequence `::` it is matched
+against the qualified type name (i.e. `namespace::Type`), otherwise it is
+matched against only the type name (i.e. `Type`). E.g. to suppress reports
+for `std::array` iterators use `std::array<.*>::(const_)?iterator` string.
+Default is an empty string.
+```
+
+````{option} IgnoreAliasing
+When `true`, the check will use the underlying type to determine the type
+that `auto` is deduced to. When `false`, the check will not look beyond
+the first type alias.
+Default is `true`.
+
+```c++
+using IntPtr = int*;
+IntPtr foo();
+
+auto bar = foo();
+```
+
+If {option}`IgnoreAliasing` is set to `true`, it will be transformed into:
+
+```c++
+auto *bar = foo();
+```
+
+Otherwise no changes will occur.
+````
+
+## Limitations
+
+When {option}`IgnoreAliasing` is set to `false`, there are cases where
Clang has not preserved the type alias and the underlying type will be used so
false positives may occur.
For example:
-.. code-block:: c++
-
- using IntPtr = int *;
+```c++
+using IntPtr = int *;
- void loopPtr(const std::vector<IntPtr> &VectorIntPtr) {
+void loopPtr(const std::vector<IntPtr> &VectorIntPtr) {
- // May fail for IgnoreAliasing==false as AST does not have the 'IntPtr'
- for (auto Data : VectorIntPtr) {
- }
+ // May fail for IgnoreAliasing==false as AST does not have the 'IntPtr'
+ for (auto Data : VectorIntPtr) {
}
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-access-specifiers.md b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-access-specifiers.md
index ee0eef9bf4088..77f5427f174b3 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-access-specifiers.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-access-specifiers.md
@@ -1,51 +1,48 @@
-.. title:: clang-tidy - readability-redundant-access-specifiers
+```{title} clang-tidy - readability-redundant-access-specifiers
+```
-readability-redundant-access-specifiers
-=======================================
+# readability-redundant-access-specifiers
Finds classes, structs, and unions containing redundant member (field and
method) access specifiers.
-Example
--------
-
-.. code-block:: c++
-
- class Foo {
- public:
- int x;
- int y;
- public:
- int z;
- protected:
- int a;
- public:
- int c;
- }
-
-In the example above, the second ``public`` declaration can be removed without
+## Example
+
+```c++
+class Foo {
+public:
+ int x;
+ int y;
+public:
+ int z;
+protected:
+ int a;
+public:
+ int c;
+}
+```
+
+In the example above, the second `public` declaration can be removed without
any changes of behavior.
-Options
--------
-
-.. option:: CheckFirstDeclaration
-
- If set to `true`, the check will also diagnose if the first access
- specifier declaration is redundant (e.g. ``private`` inside ``class``,
- or ``public`` inside ``struct`` or ``union``).
- Default is `false`.
+## Options
-Example
-^^^^^^^
+```{option} CheckFirstDeclaration
+When `true`, the check will also diagnose if the first access
+specifier declaration is redundant (e.g. `private` inside `class`,
+or `public` inside `struct` or `union`).
+Default is `false`.
+```
-.. code-block:: c++
+### Example
- struct Bar {
- public:
- int x;
- }
+```c++
+struct Bar {
+public:
+ int x;
+}
+```
-If `CheckFirstDeclaration` option is enabled, a warning about redundant
-access specifier will be emitted, because ``public`` is the default member access
+If {option}`CheckFirstDeclaration` is enabled, a warning about redundant
+access specifier will be emitted, because `public` is the default member access
for structs.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-casting.md b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-casting.md
index cd9ef09bcaf81..aa31c20fd22cf 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-casting.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-casting.md
@@ -1,50 +1,48 @@
-.. title:: clang-tidy - readability-redundant-casting
+```{title} clang-tidy - readability-redundant-casting
+```
-readability-redundant-casting
-=============================
+# readability-redundant-casting
Detects explicit type casting operations that involve the same source and
destination types, and subsequently recommend their removal. Covers a range of
-explicit casting operations, including ``static_cast``, ``const_cast``, C-style
-casts, and ``reinterpret_cast``. Its primary objective is to enhance code
+explicit casting operations, including `static_cast`, `const_cast`, C-style
+casts, and `reinterpret_cast`. Its primary objective is to enhance code
readability and maintainability by eliminating unnecessary type casting.
-.. code-block:: c++
+```c++
+int value = 42;
+int result = static_cast<int>(value);
+```
- int value = 42;
- int result = static_cast<int>(value);
-
-In this example, the ``static_cast<int>(value)`` is redundant, as it performs
-a cast from an ``int`` to another ``int``.
+In this example, the `static_cast<int>(value)` is redundant, as it performs
+a cast from an `int` to another `int`.
Casting operations involving constructor conversions, user-defined conversions,
functional casts, type-dependent casts, casts between distinct type aliases
that refer to the same underlying type, as well as bitfield-related casts and
casts directly from lvalue to rvalue, are all disregarded by the check.
-Options
--------
-
-.. option:: IgnoreMacros
-
- If set to `true`, the check will not give warnings inside macros. Default
- is `true`.
-
-.. option:: IgnoreTypeAliases
-
- When set to `false`, the check will consider type aliases, and when set to
- `true`, it will resolve all type aliases and operate on the underlying types.
- Default is `false`.
+## Options
-.. option:: IgnoreImplicitCasts
+```{option} IgnoreMacros
+When `true`, the check will not give warnings inside macros.
+Default is `true`.
+```
- When set to `false`, the check will flag casts as redundant when atleast one
- operand in an expression is implicitly cast to match the result type of the
- explicit cast. When set to `true` the casts will not be flagged. Default is
- `false`.
+```{option} IgnoreTypeAliases
+When `false`, the check will consider type aliases, and when `true`, it will
+resolve all type aliases and operate on the underlying types.
+Default is `false`.
+```
- For example, with `IgnoreImplicitCasts = false`:
+````{option} IgnoreImplicitCasts
+When `false`, the check will flag casts as redundant when at least one
+operand in an expression is implicitly cast to match the result type of the
+explicit cast. When `true`, the casts will not be flagged. Default is `false`.
- .. code-block:: c++
+For example, with {option}`IgnoreImplicitCasts` set to `false`:
- static_cast<float>(2.0f + 1); // redundant (1 implicitly converts to float)
+```c++
+static_cast<float>(2.0f + 1); // redundant (1 implicitly converts to float)
+```
+````
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-control-flow.md b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-control-flow.md
index ac435af2ac1aa..4c10979bc1da1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-control-flow.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-control-flow.md
@@ -1,51 +1,51 @@
-.. title:: clang-tidy - readability-redundant-control-flow
+```{title} clang-tidy - readability-redundant-control-flow
+```
-readability-redundant-control-flow
-==================================
+# readability-redundant-control-flow
-This check looks for procedures (functions returning no value) with ``return``
-statements at the end of the function. Such ``return`` statements are
+This check looks for procedures (functions returning no value) with `return`
+statements at the end of the function. Such `return` statements are
redundant.
-Loop statements (``for``, ``while``, ``do while``) are checked for redundant
-``continue`` statements at the end of the loop body.
+Loop statements (`for`, `while`, `do while`) are checked for redundant
+`continue` statements at the end of the loop body.
Examples:
-The following function `f` contains a redundant ``return`` statement:
+The following function `f` contains a redundant `return` statement:
-.. code-block:: c++
-
- extern void g();
- void f() {
- g();
- return;
- }
+```c++
+extern void g();
+void f() {
+ g();
+ return;
+}
+```
becomes
-.. code-block:: c++
-
- extern void g();
- void f() {
- g();
- }
-
-The following function `k` contains a redundant ``continue`` statement:
+```c++
+extern void g();
+void f() {
+ g();
+}
+```
-.. code-block:: c++
+The following function `k` contains a redundant `continue` statement:
- void k() {
- for (int i = 0; i < 10; ++i) {
- continue;
- }
+```c++
+void k() {
+ for (int i = 0; i < 10; ++i) {
+ continue;
}
+}
+```
becomes
-.. code-block:: c++
-
- void k() {
- for (int i = 0; i < 10; ++i) {
- }
+```c++
+void k() {
+ for (int i = 0; i < 10; ++i) {
}
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-declaration.md b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-declaration.md
index 2a7ecac73c4c1..86219905d6baf 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-declaration.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-declaration.md
@@ -1,37 +1,36 @@
-.. title:: clang-tidy - readability-redundant-declaration
+```{title} clang-tidy - readability-redundant-declaration
+```
-readability-redundant-declaration
-=================================
+# readability-redundant-declaration
Finds redundant variable and function declarations.
-.. code-block:: c++
-
- extern int X;
- extern int X;
+```c++
+extern int X;
+extern int X;
+```
becomes
-.. code-block:: c++
-
- extern int X;
+```c++
+extern int X;
+```
Such redundant declarations can be removed without changing program behavior.
They can for instance be unintentional left overs from previous refactorings
when code has been moved around. Having redundant declarations could in worst
case mean that there are typos in the code that cause bugs.
-Normally the code can be automatically fixed, :program:`clang-tidy` can remove
+Normally the code can be automatically fixed, {program}`clang-tidy` can remove
the second declaration. However there are 2 cases when you need to fix the code
manually:
-* When the declarations are in different header files;
-* When multiple variables are declared together.
-
-Options
--------
+- When the declarations are in different header files;
+- When multiple variables are declared together.
-.. option:: IgnoreMacros
+## Options
- If set to `true`, the check will not give warnings inside macros. Default
- is `true`.
+```{option} IgnoreMacros
+When `true`, the check will not give warnings inside macros.
+Default is `true`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-inline-specifier.md b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-inline-specifier.md
index 5ae80d54e9154..1f7ac0cd06666 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-inline-specifier.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability/redundant-inline-specifier.md
@@ -1,32 +1,31 @@
-.. title:: clang-tidy - readability-redundant-inline-specifier
+```{title} clang-tidy - readability-redundant-inline-specifier
+```
-readability-redundant-inline-specifier
-======================================
+# readability-redundant-inline-specifier
-Detects redundant ``inline`` specifiers on function and variable declarations.
+Detects redundant `inline` specifiers on function and variable declarations.
Examples:
-.. code-block:: c++
+```c++
+constexpr inline void f() {}
+```
- constexpr inline void f() {}
-
-In the example above the keyword ``inline`` is redundant since constexpr
+In the example above the keyword `inline` is redundant since constexpr
functions are implicitly inlined
-.. code-block:: c++
-
- class MyClass {
- inline void myMethod() {}
- };
+```c++
+class MyClass {
+ inline void myMethod() {}
+};
+```
-In the example above the keyword ``inline`` is redundant since member functions
+In the example above the keyword `inline` is redundant since member functions
defined entirely inside a class/struct/union definition are implicitly inlined.
-Options
--------
-
-.. option:: StrictMode
+## Options
- If set to `true`, the check will also flag functions and variables that
- already have internal linkage as redundant. Default is `false`.
+```{option} StrictMode
+When `true`, the check will also flag functions and variables that
+already have internal linkage as redundant. Default is `false`.
+```
More information about the llvm-branch-commits
mailing list