[clang-tools-extra] [clang-tidy] Rewrite remaining bugprone check docs to Markdown [2/N] (PR #212726)
Zeyi Xu via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 29 02:52:39 PDT 2026
https://github.com/zeyi2 created https://github.com/llvm/llvm-project/pull/212726
None
>From 12e1005474a5f3eac5a4e6cd4266f27f5aff4633 Mon Sep 17 00:00:00 2001
From: Zeyi Xu <mitchell.xu2 at gmail.com>
Date: Wed, 29 Jul 2026 17:52:21 +0800
Subject: [PATCH] [clang-tidy] Rewrite remaining bugprone check docs to
Markdown [2/N]
---
.../checks/bugprone/inc-dec-in-conditions.rst | 76 +++----
.../checks/bugprone/incorrect-enable-if.rst | 68 +++---
.../incorrect-enable-shared-from-this.rst | 46 ++--
.../checks/bugprone/infinite-loop.rst | 24 +--
.../checks/bugprone/integer-division.rst | 48 ++---
.../invalid-enum-default-initialization.rst | 126 ++++++-----
.../checks/bugprone/lambda-function-name.rst | 47 +++--
.../misleading-setter-of-reference.rst | 53 ++---
.../misplaced-operator-in-strlen-in-alloc.rst | 78 ++++---
.../bugprone/misplaced-widening-cast.rst | 71 +++----
.../bugprone/missing-end-comparison.rst | 138 ++++++------
.../bugprone/move-forwarding-reference.rst | 70 +++---
...ulti-level-implicit-pointer-conversion.rst | 47 ++---
.../multiple-new-in-one-expression.rst | 154 +++++++-------
.../checks/bugprone/narrowing-conversions.rst | 199 +++++++++---------
.../non-zero-enum-to-bool-conversion.rst | 70 +++---
...ndeterministic-pointer-iteration-order.rst | 46 ++--
.../bugprone/not-null-terminated-result.rst | 141 ++++++-------
.../bugprone/optional-value-conversion.rst | 91 ++++----
...inter-arithmetic-on-polymorphic-object.rst | 81 ++++---
20 files changed, 823 insertions(+), 851 deletions(-)
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst
index f3f0331b15b5e..9231cb6f2e844 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-inc-dec-in-conditions
+```{title} clang-tidy - bugprone-inc-dec-in-conditions
+```
-bugprone-inc-dec-in-conditions
-==============================
+# bugprone-inc-dec-in-conditions
Detects when a variable is both incremented/decremented and referenced inside a
complex condition and suggests moving them outside to avoid ambiguity in the
@@ -12,57 +12,57 @@ to unexpected behavior. The side-effect of changing the variable's value within
the condition can make the code difficult to reason about. Additionally, the
developer's intended timing for the modification of the variable may not be
clear, leading to misunderstandings and errors. This can be particularly
-problematic when the condition involves logical operators like ``&&`` and
-``||``, where the order of evaluation can further complicate the situation.
+problematic when the condition involves logical operators like `&&` and
+`||`, where the order of evaluation can further complicate the situation.
Consider the following example:
-.. code-block:: c++
-
- int i = 0;
- // ...
- if (i++ < 5 && i > 0) {
- // do something
- }
+```c++
+int i = 0;
+// ...
+if (i++ < 5 && i > 0) {
+ // do something
+}
+```
In this example, the result of the expression may not be what the developer
-intended. The original intention of the developer could be to increment ``i``
+intended. The original intention of the developer could be to increment `i`
after the entire condition is evaluated, but in reality, i will be incremented
-before ``i > 0`` is executed. This can lead to unexpected behavior and bugs in
+before `i > 0` is executed. This can lead to unexpected behavior and bugs in
the code. To fix this issue, the developer should separate the increment
operation from the condition and perform it separately. For example, they can
-increment ``i`` in a separate statement before or after the condition is
-evaluated. This ensures that the value of ``i`` is predictable and consistent
+increment `i` in a separate statement before or after the condition is
+evaluated. This ensures that the value of `i` is predictable and consistent
throughout the code.
-.. code-block:: c++
-
- int i = 0;
- // ...
- i++;
- if (i <= 5 && i > 0) {
- // do something
- }
+```c++
+int i = 0;
+// ...
+i++;
+if (i <= 5 && i > 0) {
+ // do something
+}
+```
Another common issue occurs when multiple increments or decrements are
performed on the same variable inside a complex condition. For example:
-.. code-block:: c++
-
- int i = 4;
- // ...
- if (i++ < 5 || --i > 2) {
- // do something
- }
+```c++
+int i = 4;
+// ...
+if (i++ < 5 || --i > 2) {
+ // do something
+}
+```
There is a potential issue with this code due to the order of evaluation in
-C++. The ``||`` operator used in the condition statement guarantees that if
-the first operand evaluates to ``true``, the second operand will not be
-evaluated. This means that if ``i`` were initially ``4``, the first operand
-``i < 5`` would evaluate to ``true`` and the second operand ``i > 2`` would
-not be evaluated. As a result, the decrement operation ``--i`` would not be
-executed and ``i`` would hold value ``5``, which may not be the intended
+C++. The `||` operator used in the condition statement guarantees that if
+the first operand evaluates to `true`, the second operand will not be
+evaluated. This means that if `i` were initially `4`, the first operand
+`i < 5` would evaluate to `true` and the second operand `i > 2` would
+not be evaluated. As a result, the decrement operation `--i` would not be
+executed and `i` would hold value `5`, which may not be the intended
behavior for the developer.
To avoid this potential issue, the both increment and decrement operation on
-``i`` should be moved outside the condition statement.
+`i` should be moved outside the condition statement.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst
index a7860a96e3081..a054d0cf80f47 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst
@@ -1,48 +1,48 @@
-.. title:: clang-tidy - bugprone-incorrect-enable-if
+```{title} clang-tidy - bugprone-incorrect-enable-if
+```
-bugprone-incorrect-enable-if
-============================
+# bugprone-incorrect-enable-if
-Detects incorrect usages of ``std::enable_if`` that don't name the nested
-``type`` type.
+Detects incorrect usages of `std::enable_if` that don't name the nested
+`type` type.
-In C++11 introduced ``std::enable_if`` as a convenient way to leverage SFINAE.
-One form of using ``std::enable_if`` is to declare an unnamed template type
+In C++11 introduced `std::enable_if` as a convenient way to leverage SFINAE.
+One form of using `std::enable_if` is to declare an unnamed template type
parameter with a default type equal to
-``typename std::enable_if<condition>::type``. If the author forgets to name
-the nested type ``type``, then the code will always consider the candidate
+`typename std::enable_if<condition>::type`. If the author forgets to name
+the nested type `type`, then the code will always consider the candidate
template even if the condition is not met.
-Below are some examples of code using ``std::enable_if`` correctly and
+Below are some examples of code using `std::enable_if` correctly and
incorrect examples that this check flags.
-.. code-block:: c++
+```c++
+template <typename T, typename = typename std::enable_if<T::some_trait>::type>
+void valid_usage() { ... }
- template <typename T, typename = typename std::enable_if<T::some_trait>::type>
- void valid_usage() { ... }
+template <typename T, typename = std::enable_if_t<T::some_trait>>
+void valid_usage_with_trait_helpers() { ... }
- template <typename T, typename = std::enable_if_t<T::some_trait>>
- void valid_usage_with_trait_helpers() { ... }
+// The below code is not a correct application of SFINAE. Even if
+// T::some_trait is not true, the function will still be considered in the
+// set of function candidates. It can either incorrectly select the function
+// when it should not be a candidates, and/or lead to hard compile errors
+// if the body of the template does not compile if the condition is not
+// satisfied.
+template <typename T, typename = std::enable_if<T::some_trait>>
+void invalid_usage() { ... }
- // The below code is not a correct application of SFINAE. Even if
- // T::some_trait is not true, the function will still be considered in the
- // set of function candidates. It can either incorrectly select the function
- // when it should not be a candidates, and/or lead to hard compile errors
- // if the body of the template does not compile if the condition is not
- // satisfied.
- template <typename T, typename = std::enable_if<T::some_trait>>
- void invalid_usage() { ... }
+// The tool suggests the following replacement for 'invalid_usage':
+template <typename T, typename = typename std::enable_if<T::some_trait>::type>
+void fixed_invalid_usage() { ... }
+```
- // The tool suggests the following replacement for 'invalid_usage':
- template <typename T, typename = typename std::enable_if<T::some_trait>::type>
- void fixed_invalid_usage() { ... }
-
-C++14 introduced the trait helper ``std::enable_if_t`` which reduces the
+C++14 introduced the trait helper `std::enable_if_t` which reduces the
likelihood of this error. C++20 introduces constraints, which generally
-supersede the use of ``std::enable_if``. See
-:doc:`modernize-type-traits <../modernize/type-traits>` for another tool
-that will replace ``std::enable_if`` with
-``std::enable_if_t``, and see
-:doc:`modernize-use-constraints <../modernize/use-constraints>` for another
-tool that replaces ``std::enable_if`` with C++20 constraints. Consider these
+supersede the use of `std::enable_if`. See
+{doc}`modernize-type-traits <../modernize/type-traits>` for another tool
+that will replace `std::enable_if` with
+`std::enable_if_t`, and see
+{doc}`modernize-use-constraints <../modernize/use-constraints>` for another
+tool that replaces `std::enable_if` with C++20 constraints. Consider these
newer mechanisms where possible.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst
index 968340a6e8f98..7608c7d7e870c 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst
@@ -1,34 +1,34 @@
-.. title:: clang-tidy - bugprone-incorrect-enable-shared-from-this
+```{title} clang-tidy - bugprone-incorrect-enable-shared-from-this
+```
-bugprone-incorrect-enable-shared-from-this
-==========================================
+# bugprone-incorrect-enable-shared-from-this
Detect classes or structs that do not publicly inherit from
-``std::enable_shared_from_this``, because unintended behavior will
-otherwise occur when calling ``shared_from_this``.
+`std::enable_shared_from_this`, because unintended behavior will
+otherwise occur when calling `shared_from_this`.
Consider the following code:
-.. code-block:: c++
+````c++
+#include <memory>
- #include <memory>
+// private inheritance
+class BadExample : std::enable_shared_from_this<BadExample> {
- // private inheritance
- class BadExample : std::enable_shared_from_this<BadExample> {
+// ``shared_from_this``` unintended behaviour
+// `libstdc++` implementation returns uninitialized ``weak_ptr``
+ public:
+ BadExample* foo() { return shared_from_this().get(); }
+ void bar() { return; }
+};
- // ``shared_from_this``` unintended behaviour
- // `libstdc++` implementation returns uninitialized ``weak_ptr``
- public:
- BadExample* foo() { return shared_from_this().get(); }
- void bar() { return; }
- };
+void using_not_public() {
+ auto bad_example = std::make_shared<BadExample>();
+ auto* b_ex = bad_example->foo();
+ b_ex->bar();
+}
+````
- void using_not_public() {
- auto bad_example = std::make_shared<BadExample>();
- auto* b_ex = bad_example->foo();
- b_ex->bar();
- }
-
-Using `libstdc++` implementation, ``shared_from_this`` will throw
-``std::bad_weak_ptr``. When ``using_not_public()`` is called, this code will
+Using `libstdc++` implementation, `shared_from_this` will throw
+`std::bad_weak_ptr`. When `using_not_public()` is called, this code will
crash without exception handling.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst
index bbbc8773868a4..14d861c3ca4fd 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-infinite-loop
+```{title} clang-tidy - bugprone-infinite-loop
+```
-bugprone-infinite-loop
-======================
+# bugprone-infinite-loop
Finds obvious infinite loops (loops where the condition variable is not changed
at all).
@@ -9,9 +9,9 @@ at all).
Finding infinite loops is well-known to be impossible (halting problem).
However, it is possible to detect some obvious infinite loops, for example, if
the loop condition is not changed. This check detects such loops. A loop is
-considered infinite if it does not have any loop exit statement (``break``,
-``continue``, ``goto``, ``return``, ``throw`` or a call to a function called as
-``[[noreturn]]``) and all of the following conditions hold for every variable
+considered infinite if it does not have any loop exit statement (`break`,
+`continue`, `goto`, `return`, `throw` or a call to a function called as
+`[[noreturn]]`) and all of the following conditions hold for every variable
in the condition:
- It is a local variable.
@@ -24,9 +24,9 @@ loop infinite since functions may return different values for different calls.
For example, the following loop is considered infinite `i` is not changed in
the body:
-.. code-block:: c++
-
- int i = 0, j = 0;
- while (i < 10) {
- ++j;
- }
+```c++
+int i = 0, j = 0;
+while (i < 10) {
+ ++j;
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst
index 2c82e6fa18a3d..35ff24b0225fc 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-integer-division
+```{title} clang-tidy - bugprone-integer-division
+```
-bugprone-integer-division
-=========================
+# bugprone-integer-division
Finds cases where integer division in a floating point context is likely to
cause unintended loss of precision.
@@ -16,24 +16,24 @@ as these are interpreted as signs of deliberateness from the programmer.
Examples:
-.. code-block:: c++
-
- float floatFunc(float);
- int intFunc(int);
- double d;
- int i = 42;
-
- // Warn, floating-point values expected.
- d = 32 * 8 / (2 + i);
- d = 8 * floatFunc(1 + 7 / 2);
- d = i / (1 << 4);
-
- // OK, no integer division.
- d = 32 * 8.0 / (2 + i);
- d = 8 * floatFunc(1 + 7.0 / 2);
- d = (double)i / (1 << 4);
-
- // OK, there are signs of deliberateness.
- d = 1 << (i / 2);
- d = 9 + intFunc(6 * i / 32);
- d = (int)(i / 32) - 8;
+```c++
+float floatFunc(float);
+int intFunc(int);
+double d;
+int i = 42;
+
+// Warn, floating-point values expected.
+d = 32 * 8 / (2 + i);
+d = 8 * floatFunc(1 + 7 / 2);
+d = i / (1 << 4);
+
+// OK, no integer division.
+d = 32 * 8.0 / (2 + i);
+d = 8 * floatFunc(1 + 7.0 / 2);
+d = (double)i / (1 << 4);
+
+// OK, there are signs of deliberateness.
+d = 1 << (i / 2);
+d = 9 + intFunc(6 * i / 32);
+d = (int)(i / 32) - 8;
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst
index fcbfce751828d..7ab9e51bbdc91 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst
@@ -1,84 +1,82 @@
-.. title:: clang-tidy - bugprone-invalid-enum-default-initialization
+```{title} clang-tidy - bugprone-invalid-enum-default-initialization
+```
-bugprone-invalid-enum-default-initialization
-============================================
+# bugprone-invalid-enum-default-initialization
-Detects default initialization (to 0) of variables with ``enum`` type where
+Detects default initialization (to 0) of variables with `enum` type where
the enum has no enumerator with value of 0.
In C++ a default initialization is performed if a variable is initialized with
initializer list or in other implicit ways, and no value is specified at the
initialization. In such cases the value 0 is used for the initialization.
This also applies to enumerations even if it does not have an enumerator with
-value 0. In this way a variable with the ``enum`` type may contain initially an
+value 0. In this way a variable with the `enum` type may contain initially an
invalid value (if the program expects that it contains only the listed
enumerator values).
-The check emits a warning only if an ``enum`` variable is default-initialized
-(contrary to not initialized) and the ``enum`` does not have an enumerator with
-value of 0. The type can be a scoped or non-scoped ``enum``. Unions are not
+The check emits a warning only if an `enum` variable is default-initialized
+(contrary to not initialized) and the `enum` does not have an enumerator with
+value of 0. The type can be a scoped or non-scoped `enum`. Unions are not
handled by the check (if it contains a member of enumeration type).
-Note that the ``enum`` ``std::errc`` is always ignored because it is expected
+Note that the `enum` `std::errc` is always ignored because it is expected
to be default initialized, despite not defining an enumerator with the value 0.
-.. code-block:: c++
-
- enum class Enum1: int {
- A = 1,
- B
- };
-
- enum class Enum0: int {
- A = 0,
- B
- };
-
- void f() {
- Enum1 X1{}; // warn: 'X1' is initialized to 0
- Enum1 X2 = Enum1(); // warn: 'X2' is initialized to 0
- Enum1 X3; // no warning: 'X3' is not initialized
- Enum0 X4{}; // no warning: type has an enumerator with value of 0
- }
-
- struct S1 {
- Enum1 A;
- S(): A() {} // warn: 'A' is initialized to 0
- };
-
- struct S2 {
- int A;
- Enum1 B;
- };
-
- S2 VarS2{}; // warn: member 'B' is initialized to 0
+```c++
+enum class Enum1: int {
+ A = 1,
+ B
+};
+
+enum class Enum0: int {
+ A = 0,
+ B
+};
+
+void f() {
+ Enum1 X1{}; // warn: 'X1' is initialized to 0
+ Enum1 X2 = Enum1(); // warn: 'X2' is initialized to 0
+ Enum1 X3; // no warning: 'X3' is not initialized
+ Enum0 X4{}; // no warning: type has an enumerator with value of 0
+}
+
+struct S1 {
+ Enum1 A;
+ S(): A() {} // warn: 'A' is initialized to 0
+};
+
+struct S2 {
+ int A;
+ Enum1 B;
+};
+
+S2 VarS2{}; // warn: member 'B' is initialized to 0
+```
The check applies to initialization of arrays or structures with initialization
lists in C code too. In these cases elements not specified in the list (and have
enum type) are set to 0.
-.. code-block:: c
-
- enum Enum1 {
- Enum1_A = 1,
- Enum1_B
- };
- struct Struct1 {
- int a;
- enum Enum1 b;
- };
-
- enum Enum1 Array1[2] = {Enum1_A}; // warn: omitted elements are initialized to 0
- enum Enum1 Array2[2][2] = {{Enum1_A}, {Enum1_A}}; // warn: last element of both nested arrays is initialized to 0
- enum Enum1 Array3[2][2] = {{Enum1_A, Enum1_A}}; // warn: elements of second array are initialized to 0
-
- struct Struct1 S1 = {1}; // warn: element 'b' is initialized to 0
-
-
-Options
--------
-
-.. option:: IgnoredEnums
-
- Semicolon-separated list of regexes specifying enums for which this check won't be
- enforced. Default is `::std::errc`.
+```c
+enum Enum1 {
+ Enum1_A = 1,
+ Enum1_B
+};
+struct Struct1 {
+ int a;
+ enum Enum1 b;
+};
+
+enum Enum1 Array1[2] = {Enum1_A}; // warn: omitted elements are initialized to 0
+enum Enum1 Array2[2][2] = {{Enum1_A}, {Enum1_A}}; // warn: last element of both nested arrays is initialized to 0
+enum Enum1 Array3[2][2] = {{Enum1_A, Enum1_A}}; // warn: elements of second array are initialized to 0
+
+struct Struct1 S1 = {1}; // warn: element 'b' is initialized to 0
+```
+
+## Options
+
+```{option} IgnoredEnums
+Semicolon-separated list of regexes specifying enums for which this check won't be
+enforced. Default is `::std::errc`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.rst
index e9cbf2b46b2bc..47d49206e14da 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.rst
@@ -1,35 +1,38 @@
-.. title:: clang-tidy - bugprone-lambda-function-name
+```{title} clang-tidy - bugprone-lambda-function-name
+```
-bugprone-lambda-function-name
-=============================
+# bugprone-lambda-function-name
Checks for attempts to get the name of a function from within a lambda
-expression. The name of a lambda is always something like ``operator()``, which
+expression. The name of a lambda is always something like `operator()`, which
is almost never what was intended.
Example:
-.. code-block:: c++
+```c++
+void FancyFunction() {
+ [] { printf("Called from %s\n", __func__); }();
+ [] { printf("Now called from %s\n", __FUNCTION__); }();
+}
+```
- void FancyFunction() {
- [] { printf("Called from %s\n", __func__); }();
- [] { printf("Now called from %s\n", __FUNCTION__); }();
- }
+Output:
-Output::
+```
+Called from operator()
+Now called from operator()
+```
- Called from operator()
- Now called from operator()
+Likely intended output:
-Likely intended output::
+```
+Called from FancyFunction
+Now called from FancyFunction
+```
- Called from FancyFunction
- Now called from FancyFunction
+## Options
-Options
--------
-
-.. option:: IgnoreMacros
-
- The value `true` specifies that attempting to get the name of a function from
- within a macro should not be diagnosed. The default value is `false`.
+```{option} IgnoreMacros
+The value `true` specifies that attempting to get the name of a function from
+within a macro should not be diagnosed. The default value is `false`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.rst
index 43da9ae0ad199..bf9fc46b2e77a 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-misleading-setter-of-reference
+```{title} clang-tidy - bugprone-misleading-setter-of-reference
+```
-bugprone-misleading-setter-of-reference
-=======================================
+# bugprone-misleading-setter-of-reference
Finds setter-like member functions that take a pointer parameter and set a
reference member of the same class with the pointed value.
@@ -16,31 +16,32 @@ pointed-to (or referenced) value.
Example:
-.. code-block:: c++
+```c++
+class MyClass {
+ int &InternalRef; // non-const reference member
+public:
+ MyClass(int &Value) : InternalRef(Value) {}
- class MyClass {
- int &InternalRef; // non-const reference member
- public:
- MyClass(int &Value) : InternalRef(Value) {}
-
- // Warning: This setter could lead to unintended behaviour.
- void setRef(int *Value) {
- InternalRef = *Value; // This assigns to the referenced value, not changing what InternalRef references.
- }
- };
+ // Warning: This setter could lead to unintended behaviour.
+ void setRef(int *Value) {
+ InternalRef = *Value; // This assigns to the referenced value, not changing what InternalRef references.
+ }
+};
- int main() {
- int Value1 = 42;
- int Value2 = 100;
- MyClass X(Value1);
+int main() {
+ int Value1 = 42;
+ int Value2 = 100;
+ MyClass X(Value1);
- // This might look like it changes what InternalRef references to,
- // but it actually modifies Value1 to be 100.
- X.setRef(&Value2);
- }
+ // This might look like it changes what InternalRef references to,
+ // but it actually modifies Value1 to be 100.
+ X.setRef(&Value2);
+}
+```
Possible fixes:
- - Change the parameter type of the "set" function to non-pointer type (for
- example, a const reference).
- - Change the type of the member variable to a pointer and in the "set"
- function assign a value to the pointer (without dereference).
+
+- Change the parameter type of the "set" function to non-pointer type (for
+ example, a const reference).
+- Change the type of the member variable to a pointer and in the "set"
+ function assign a value to the pointer (without dereference).
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst
index c9a2a648578ce..c58bda450d928 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst
@@ -1,57 +1,53 @@
-.. title:: clang-tidy - bugprone-misplaced-operator-in-strlen-in-alloc
-
-bugprone-misplaced-operator-in-strlen-in-alloc
-==============================================
-
-Finds cases where ``1`` is added to the string in the argument to ``strlen()``,
-``strnlen()``, ``strnlen_s()``, ``wcslen()``, ``wcsnlen()``, and
-``wcsnlen_s()`` instead of the result and the value is used as an argument to a
-memory allocation function (``malloc()``, ``calloc()``, ``realloc()``,
-``alloca()``) or the ``new[]`` operator in `C++`. The check detects error cases
-even if one of these functions (except the ``new[]`` operator) is called by a
-constant function pointer. Cases where ``1`` is added both to the parameter and
-the result of the ``strlen()``-like function are ignored, as are cases where
+```{title} clang-tidy - bugprone-misplaced-operator-in-strlen-in-alloc
+```
+
+# bugprone-misplaced-operator-in-strlen-in-alloc
+
+Finds cases where `1` is added to the string in the argument to `strlen()`,
+`strnlen()`, `strnlen_s()`, `wcslen()`, `wcsnlen()`, and
+`wcsnlen_s()` instead of the result and the value is used as an argument to a
+memory allocation function (`malloc()`, `calloc()`, `realloc()`,
+`alloca()`) or the `new[]` operator in `C++`. The check detects error cases
+even if one of these functions (except the `new[]` operator) is called by a
+constant function pointer. Cases where `1` is added both to the parameter and
+the result of the `strlen()`-like function are ignored, as are cases where
the whole addition is surrounded by extra parentheses.
`C` example code:
-.. code-block:: c
+```c
+void bad_malloc(char *str) {
+ char *c = (char*) malloc(strlen(str + 1));
+}
+```
- void bad_malloc(char *str) {
- char *c = (char*) malloc(strlen(str + 1));
- }
-
-
-The suggested fix is to add ``1`` to the return value of ``strlen()`` and not
+The suggested fix is to add `1` to the return value of `strlen()` and not
to its argument. In the example above the fix would be
-.. code-block:: c
-
- char *c = (char*) malloc(strlen(str) + 1);
-
+```c
+char *c = (char*) malloc(strlen(str) + 1);
+```
`C++` example code:
-.. code-block:: c++
-
- void bad_new(char *str) {
- char *c = new char[strlen(str + 1)];
- }
+```c++
+void bad_new(char *str) {
+ char *c = new char[strlen(str + 1)];
+}
+```
-
-As in the `C` code with the ``malloc()`` function, the suggested fix is to
-add ``1`` to the return value of ``strlen()`` and not to its argument. In the
+As in the `C` code with the `malloc()` function, the suggested fix is to
+add `1` to the return value of `strlen()` and not to its argument. In the
example above the fix would be
-.. code-block:: c++
-
- char *c = new char[strlen(str) + 1];
-
+```c++
+char *c = new char[strlen(str) + 1];
+```
Example for silencing the diagnostic:
-.. code-block:: c
-
- void bad_malloc(char *str) {
- char *c = (char*) malloc(strlen((str + 1)));
- }
+```c
+void bad_malloc(char *str) {
+ char *c = (char*) malloc(strlen((str + 1)));
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.rst
index cec49c55309ad..2474e77dc1502 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-misplaced-widening-cast
+```{title} clang-tidy - bugprone-misplaced-widening-cast
+```
-bugprone-misplaced-widening-cast
-================================
+# bugprone-misplaced-widening-cast
This check will warn when there is a cast of a calculation result to a bigger
type. If the intention of the cast is to avoid loss of precision then the cast
@@ -10,56 +10,53 @@ ineffective.
Example code:
-.. code-block:: c++
+```c++
+long f(int x) {
+ return (long)(x * 1000);
+}
+```
- long f(int x) {
- return (long)(x * 1000);
- }
-
-The result ``x * 1000`` is first calculated using ``int`` precision. If the
-result exceeds ``int`` precision there is loss of precision. Then the result is
-casted to ``long``.
+The result `x * 1000` is first calculated using `int` precision. If the
+result exceeds `int` precision there is loss of precision. Then the result is
+casted to `long`.
If there is no loss of precision then the cast can be removed or you can
-explicitly cast to ``int`` instead.
+explicitly cast to `int` instead.
If you want to avoid loss of precision then put the cast in a proper location,
for instance:
-.. code-block:: c++
-
- long f(int x) {
- return (long)x * 1000;
- }
+```c++
+long f(int x) {
+ return (long)x * 1000;
+}
+```
-Implicit casts
---------------
+## Implicit casts
Forgetting to place the cast at all is at least as dangerous and at least as
-common as misplacing it. If :option:`CheckImplicitCasts` is enabled the check
+common as misplacing it. If {option}`CheckImplicitCasts` is enabled the check
also detects these cases, for instance:
-.. code-block:: c++
-
- long f(int x) {
- return x * 1000;
- }
+```c++
+long f(int x) {
+ return x * 1000;
+}
+```
-Floating point
---------------
+## Floating point
Currently warnings are only written for integer conversion. No warning is
written for this code:
-.. code-block:: c++
-
- double f(float x) {
- return (double)(x * 10.0f);
- }
-
-Options
--------
+```c++
+double f(float x) {
+ return (double)(x * 10.0f);
+}
+```
-.. option:: CheckImplicitCasts
+## Options
- If `true`, enables detection of implicit casts. Default is `false`.
+```{option} CheckImplicitCasts
+If `true`, enables detection of implicit casts. Default is `false`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.rst
index 33d2f071c1dc2..4951b4266d1e9 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.rst
@@ -1,91 +1,89 @@
-.. title:: clang-tidy - bugprone-missing-end-comparison
+```{title} clang-tidy - bugprone-missing-end-comparison
+```
-bugprone-missing-end-comparison
-===============================
+# bugprone-missing-end-comparison
Finds instances where the result of a standard algorithm is used in a Boolean
context without being compared to the end iterator.
-Standard algorithms such as ``std::find``, ``std::search``, and
-``std::lower_bound`` return an iterator to the element if found, or the end
+Standard algorithms such as `std::find`, `std::search`, and
+`std::lower_bound` return an iterator to the element if found, or the end
iterator otherwise.
-Using the result directly in a Boolean context (like an ``if`` statement) is
+Using the result directly in a Boolean context (like an `if` statement) is
almost always a bug, as it only checks if the iterator itself evaluates to
-``true``, which may always be true for many iterator types.
+`true`, which may always be true for many iterator types.
Examples:
-.. code-block:: c++
+```c++
+void example() {
+ int arr[] = {1, 2, 3};
+ int* begin = std::begin(arr);
+ int* end = std::end(arr);
- void example() {
- int arr[] = {1, 2, 3};
- int* begin = std::begin(arr);
- int* end = std::end(arr);
-
- if (std::find(begin, end, 2)) {
- // ...
- }
+ if (std::find(begin, end, 2)) {
+ // ...
+ }
- // Fixed by the check:
- if ((std::find(begin, end, 2) != end)) {
- // ...
- }
+ // Fixed by the check:
+ if ((std::find(begin, end, 2) != end)) {
+ // ...
+ }
- // C++20 ranges:
- int v[] = {1, 2, 3};
- if (std::ranges::find(v, 2)) {
- // ...
- }
+ // C++20 ranges:
+ int v[] = {1, 2, 3};
+ if (std::ranges::find(v, 2)) {
+ // ...
+ }
- // Fixed by the check:
- if ((std::ranges::find(v, 2) != std::ranges::end(v))) {
- // ...
- }
+ // Fixed by the check:
+ if ((std::ranges::find(v, 2) != std::ranges::end(v))) {
+ // ...
}
+}
+```
The check also handles range-based algorithms introduced in C++20.
Supported algorithms:
-- ``std::adjacent_find``
-- ``std::find``
-- ``std::find_end``
-- ``std::find_first_of``
-- ``std::find_if``
-- ``std::find_if_not``
-- ``std::is_sorted_until``
-- ``std::lower_bound``
-- ``std::max_element``
-- ``std::min_element``
-- ``std::partition_point``
-- ``std::search``
-- ``std::search_n``
-- ``std::upper_bound``
-- ``std::ranges::adjacent_find``
-- ``std::ranges::find``
-- ``std::ranges::find_first_of``
-- ``std::ranges::find_if``
-- ``std::ranges::find_if_not``
-- ``std::ranges::is_sorted_until``
-- ``std::ranges::lower_bound``
-- ``std::ranges::max_element``
-- ``std::ranges::min_element``
-- ``std::ranges::upper_bound``
-
-Options
--------
-
-.. option:: ExtraAlgorithms
-
- A semicolon-separated list of extra algorithms to check.
- The list can contain:
-
- - Iterator-based algorithms. These should follow the standard iterator
- pattern: ``func(Iter, Iter, ...)``.
-
- - Range-based algorithms. These are heuristically detected if they take
- exactly two arguments and the first argument is a container or range.
- The fix will insert ``std::end(Container)``.
-
- Default is an empty string.
+- `std::adjacent_find`
+- `std::find`
+- `std::find_end`
+- `std::find_first_of`
+- `std::find_if`
+- `std::find_if_not`
+- `std::is_sorted_until`
+- `std::lower_bound`
+- `std::max_element`
+- `std::min_element`
+- `std::partition_point`
+- `std::search`
+- `std::search_n`
+- `std::upper_bound`
+- `std::ranges::adjacent_find`
+- `std::ranges::find`
+- `std::ranges::find_first_of`
+- `std::ranges::find_if`
+- `std::ranges::find_if_not`
+- `std::ranges::is_sorted_until`
+- `std::ranges::lower_bound`
+- `std::ranges::max_element`
+- `std::ranges::min_element`
+- `std::ranges::upper_bound`
+
+## Options
+
+```{option} ExtraAlgorithms
+A semicolon-separated list of extra algorithms to check.
+The list can contain:
+
+- Iterator-based algorithms. These should follow the standard iterator
+ pattern: `func(Iter, Iter, ...)`.
+- Range-based algorithms. These are heuristically detected if they take
+ exactly two arguments and the first argument is a container or range.
+ The fix will insert `std::end(Container)`.
+
+Default is an empty string.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.rst
index b249ac6d32ccc..f498fad2ce731 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.rst
@@ -1,20 +1,19 @@
-.. title:: clang-tidy - bugprone-move-forwarding-reference
+```{title} clang-tidy - bugprone-move-forwarding-reference
+```
-bugprone-move-forwarding-reference
-==================================
+# bugprone-move-forwarding-reference
-Warns if ``std::move`` is called on a forwarding reference, for example:
+Warns if `std::move` is called on a forwarding reference, for example:
-.. code-block:: c++
+```c++
+template <typename T>
+void foo(T&& t) {
+ bar(std::move(t));
+}
+```
- template <typename T>
- void foo(T&& t) {
- bar(std::move(t));
- }
-
-`Forwarding references
-<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4164.pdf>`_ should
-typically be passed to ``std::forward`` instead of ``std::move``, and this is
+[Forwarding references](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4164.pdf) should
+typically be passed to `std::forward` instead of `std::move`, and this is
the fix that will be suggested.
(A forwarding reference is an rvalue reference of a type that is a deduced
@@ -22,39 +21,38 @@ function template argument.)
In this example, the suggested fix would be
-.. code-block:: c++
-
- bar(std::forward<T>(t));
+```c++
+bar(std::forward<T>(t));
+```
-Background
-----------
+## Background
Code like the example above is sometimes written with the expectation that
-``T&&`` will always end up being an rvalue reference, no matter what type is
-deduced for ``T``, and that it is therefore not possible to pass an lvalue to
-``foo()``. However, this is not true. Consider this example:
-
-.. code-block:: c++
+`T&&` will always end up being an rvalue reference, no matter what type is
+deduced for `T`, and that it is therefore not possible to pass an lvalue to
+`foo()`. However, this is not true. Consider this example:
- std::string s = "Hello, world";
- foo(s);
+```c++
+std::string s = "Hello, world";
+foo(s);
+```
-This code compiles and, after the call to ``foo()``, ``s`` is left in an
+This code compiles and, after the call to `foo()`, `s` is left in an
indeterminate state because it has been moved from. This may be surprising to
-the caller of ``foo()`` because no ``std::move`` was used when calling
-``foo()``.
+the caller of `foo()` because no `std::move` was used when calling
+`foo()`.
The reason for this behavior lies in the special rule for template argument
-deduction on function templates like ``foo()`` -- i.e. on function templates
+deduction on function templates like `foo()` -- i.e. on function templates
that take an rvalue reference argument of a type that is a deduced function
template argument. (See section [temp.deduct.call]/3 in the C++11 standard.)
-If ``foo()`` is called on an lvalue (as in the example above), then ``T`` is
-deduced to be an lvalue reference. In the example, ``T`` is deduced to be
-``std::string &``. The type of the argument ``t`` therefore becomes
-``std::string& &&``; by the reference collapsing rules, this collapses to
-``std::string&``.
+If `foo()` is called on an lvalue (as in the example above), then `T` is
+deduced to be an lvalue reference. In the example, `T` is deduced to be
+`std::string &`. The type of the argument `t` therefore becomes
+`std::string& &&`; by the reference collapsing rules, this collapses to
+`std::string&`.
-This means that the ``foo(s)`` call passes ``s`` as an lvalue reference, and
-``foo()`` ends up moving ``s`` and thereby placing it into an indeterminate
+This means that the `foo(s)` call passes `s` as an lvalue reference, and
+`foo()` ends up moving `s` and thereby placing it into an indeterminate
state.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multi-level-implicit-pointer-conversion.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multi-level-implicit-pointer-conversion.rst
index 14df6bd9ccea9..f6fef1a90177d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multi-level-implicit-pointer-conversion.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multi-level-implicit-pointer-conversion.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-multi-level-implicit-pointer-conversion
+```{title} clang-tidy - bugprone-multi-level-implicit-pointer-conversion
+```
-bugprone-multi-level-implicit-pointer-conversion
-================================================
+# bugprone-multi-level-implicit-pointer-conversion
Detects implicit conversions between pointers of different levels of
indirection.
@@ -9,8 +9,8 @@ indirection.
Conversions between pointer types of different levels of indirection can be
dangerous and may lead to undefined behavior, particularly if the converted
pointer is later cast to a type with a different level of indirection.
-For example, converting a pointer to a pointer to an ``int`` (``int**``) to
-a ``void*`` can result in the loss of information about the original level of
+For example, converting a pointer to a pointer to an `int` (`int**`) to
+a `void*` can result in the loss of information about the original level of
indirection, which can cause problems when attempting to use the converted
pointer. If the converted pointer is later cast to a type with a different
level of indirection and dereferenced, it may lead to access violations,
@@ -18,22 +18,22 @@ memory corruption, or other undefined behavior.
Consider the following example:
-.. code-block:: c++
+```c++
+void foo(void* ptr);
- void foo(void* ptr);
+int main() {
+ int x = 42;
+ int* ptr = &x;
+ int** ptr_ptr = &ptr;
+ foo(ptr_ptr); // warning will trigger here
+ return 0;
+}
+```
- int main() {
- int x = 42;
- int* ptr = &x;
- int** ptr_ptr = &ptr;
- foo(ptr_ptr); // warning will trigger here
- return 0;
- }
-
-In this example, ``foo()`` is called with ``ptr_ptr`` as its argument. However,
-``ptr_ptr`` is a ``int**`` pointer, while ``foo()`` expects a ``void*`` pointer.
+In this example, `foo()` is called with `ptr_ptr` as its argument. However,
+`ptr_ptr` is a `int**` pointer, while `foo()` expects a `void*` pointer.
This results in an implicit pointer level conversion, which could cause issues
-if ``foo()`` dereferences the pointer assuming it's a ``int*`` pointer.
+if `foo()` dereferences the pointer assuming it's a `int*` pointer.
Using an explicit cast is a recommended solution to prevent issues caused by
implicit pointer level conversion, as it allows the developer to explicitly
@@ -43,10 +43,9 @@ safety of the conversion before using an explicit cast. This extra level of
caution can help catch potential issues early on in the development process,
improving the overall reliability and maintainability of the code.
-Options
--------
-
-.. option:: EnableInC
+## Options
- If `true`, enables the check in C code (it is always enabled in C++ code).
- Default is `true`.
+```{option} EnableInC
+If `true`, enables the check in C code (it is always enabled in C++ code).
+Default is `true`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst
index 154013da516d3..dae48f810fb55 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst
@@ -1,35 +1,35 @@
-.. title:: clang-tidy - bugprone-multiple-new-in-one-expression
+```{title} clang-tidy - bugprone-multiple-new-in-one-expression
+```
-bugprone-multiple-new-in-one-expression
-=======================================
+# bugprone-multiple-new-in-one-expression
-Finds multiple ``new`` operator calls in a single expression, where the
-allocated memory by the first ``new`` may leak if the second allocation fails
+Finds multiple `new` operator calls in a single expression, where the
+allocated memory by the first `new` may leak if the second allocation fails
and throws exception.
C++ does often not specify the exact order of evaluation of the operands of an
operator or arguments of a function. Therefore if a first allocation succeeds
and a second fails, in an exception handler it is not possible to tell which
allocation has failed and free the memory. Even if the order is fixed the
-result of a first ``new`` may be stored in a temporary location that is not
+result of a first `new` may be stored in a temporary location that is not
reachable at the time when a second allocation fails. It is best to avoid any
-expression that contains more than one ``operator new`` call, if exception
+expression that contains more than one `operator new` call, if exception
handling is used to check for allocation errors.
-Different rules apply for are the short-circuit operators ``||`` and ``&&`` and
-the ``,`` operator, where evaluation of one side must be completed before the
+Different rules apply for are the short-circuit operators `||` and `&&` and
+the `,` operator, where evaluation of one side must be completed before the
other starts. Expressions of a list-initialization (initialization or
-construction using ``{`` and ``}`` characters) are evaluated in fixed order.
-Similarly, condition of a ``?`` operator is evaluated before the branches are
+construction using `{` and `}` characters) are evaluated in fixed order.
+Similarly, condition of a `?` operator is evaluated before the branches are
evaluated.
-The check reports warning if two ``new`` calls appear in one expression at
-different sides of an operator, or if ``new`` calls appear in different
-arguments of a function call (that can be an object construction with ``()``
-syntax). These ``new`` calls can be nested at any level.
-For any warning to be emitted the ``new`` calls should be in a code block where
-exception handling is used with catch for ``std::bad_alloc`` or
-``std::exception``. At ``||``, ``&&``, ``,``, ``?`` (condition and one branch)
+The check reports warning if two `new` calls appear in one expression at
+different sides of an operator, or if `new` calls appear in different
+arguments of a function call (that can be an object construction with `()`
+syntax). These `new` calls can be nested at any level.
+For any warning to be emitted the `new` calls should be in a code block where
+exception handling is used with catch for `std::bad_alloc` or
+`std::exception`. At `||`, `&&`, `,`, `?` (condition and one branch)
operators no warning is emitted. No warning is emitted if both of the memory
allocations are not assigned to a variable or not passed directly to a
function. The reason is that in this case the memory may be intentionally not
@@ -37,63 +37,63 @@ freed or the allocated objects can be self-destructing objects.
Examples:
-.. code-block:: c++
-
- struct A {
- int Var;
- };
- struct B {
- B();
- B(A *);
- int Var;
- };
- struct C {
- int *X1;
- int *X2;
- };
-
- void f(A *, B *);
- int f1(A *);
- int f1(B *);
- bool f2(A *);
-
- void foo() {
- A *PtrA;
- B *PtrB;
- try {
- // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated.
- f(new A, new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
-
- // List (aggregate) initialization is used.
- C C1{new int, new int}; // no warning
-
- // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated but not yet passed to function 'f1'.
- int X = f1(new A) + f1(new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
-
- // Allocation of 'B' may fail after memory for 'A' was allocated.
- // From C++17 on memory for 'B' is allocated first but still may leak if allocation of 'A' fails.
- PtrB = new B(new A); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception
-
- // 'new A' and 'new B' may be performed in any order.
- // 'new B'/'new A' may fail after memory for 'A'/'B' was allocated but not assigned to 'PtrA'/'PtrB'.
- (PtrA = new A)->Var = (PtrB = new B)->Var; // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
-
- // Evaluation of 'f2(new A)' must be finished before 'f1(new B)' starts.
- // If 'new B' fails the allocated memory for 'A' is supposedly handled correctly because function 'f2' could take the ownership.
- bool Z = f2(new A) || f1(new B); // no warning
-
- X = (f2(new A) ? f1(new A) : f1(new B)); // no warning
-
- // No warning if the result of both allocations is not passed to a function
- // or stored in a variable.
- (new A)->Var = (new B)->Var; // no warning
-
- // No warning if at least one non-throwing allocation is used.
- f(new(std::nothrow) A, new B); // no warning
- } catch(std::bad_alloc) {
- }
-
- // No warning if the allocation is outside a try block (or no catch handler exists for std::bad_alloc).
- // (The fact if exceptions can escape from 'foo' is not taken into account.)
- f(new A, new B); // no warning
+```c++
+struct A {
+ int Var;
+};
+struct B {
+ B();
+ B(A *);
+ int Var;
+};
+struct C {
+ int *X1;
+ int *X2;
+};
+
+void f(A *, B *);
+int f1(A *);
+int f1(B *);
+bool f2(A *);
+
+void foo() {
+ A *PtrA;
+ B *PtrB;
+ try {
+ // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated.
+ f(new A, new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
+
+ // List (aggregate) initialization is used.
+ C C1{new int, new int}; // no warning
+
+ // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated but not yet passed to function 'f1'.
+ int X = f1(new A) + f1(new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
+
+ // Allocation of 'B' may fail after memory for 'A' was allocated.
+ // From C++17 on memory for 'B' is allocated first but still may leak if allocation of 'A' fails.
+ PtrB = new B(new A); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception
+
+ // 'new A' and 'new B' may be performed in any order.
+ // 'new B'/'new A' may fail after memory for 'A'/'B' was allocated but not assigned to 'PtrA'/'PtrB'.
+ (PtrA = new A)->Var = (PtrB = new B)->Var; // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
+
+ // Evaluation of 'f2(new A)' must be finished before 'f1(new B)' starts.
+ // If 'new B' fails the allocated memory for 'A' is supposedly handled correctly because function 'f2' could take the ownership.
+ bool Z = f2(new A) || f1(new B); // no warning
+
+ X = (f2(new A) ? f1(new A) : f1(new B)); // no warning
+
+ // No warning if the result of both allocations is not passed to a function
+ // or stored in a variable.
+ (new A)->Var = (new B)->Var; // no warning
+
+ // No warning if at least one non-throwing allocation is used.
+ f(new(std::nothrow) A, new B); // no warning
+ } catch(std::bad_alloc) {
}
+
+ // No warning if the allocation is outside a try block (or no catch handler exists for std::bad_alloc).
+ // (The fact if exceptions can escape from 'foo' is not taken into account.)
+ f(new A, new B); // no warning
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst
index 4327bc09babab..fc1e6966d24da 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst
@@ -1,123 +1,122 @@
-.. title:: clang-tidy - bugprone-narrowing-conversions
+```{title} clang-tidy - bugprone-narrowing-conversions
+```
-bugprone-narrowing-conversions
-==============================
+# bugprone-narrowing-conversions
`cppcoreguidelines-narrowing-conversions` redirects here as an alias for
this check.
-Checks for silent narrowing conversions, e.g: ``int i = 0; i += 0.1;``. While
+Checks for silent narrowing conversions, e.g: `int i = 0; i += 0.1;`. While
the issue is obvious in this former example, it might not be so in the
-following: ``void MyClass::f(double d) { int_member_ += d; }``.
+following: `void MyClass::f(double d) { int_member_ += d; }`.
We flag narrowing conversions from:
- - an integer to a narrower integer (e.g. ``char`` to ``unsigned char``)
- if WarnOnIntegerNarrowingConversion Option is set,
- - an integer to a narrower floating-point (e.g. ``uint64_t`` to ``float``)
- if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
- - a floating-point to an integer (e.g. ``double`` to ``int``),
- - a floating-point to a narrower floating-point (e.g. ``double`` to ``float``)
- if WarnOnFloatingPointNarrowingConversion Option is set.
-This check will flag:
- - All narrowing conversions that are not marked by an explicit cast (c-style
- or ``static_cast``). For example: ``int i = 0; i += 0.1;``,
- ``void f(int); f(0.1);``,
- - All applications of binary operators with a narrowing conversions.
- For example: ``int i; i+= 0.1;``.
-
-Arithmetic with smaller integer types than ``int`` trigger implicit conversions,
-as explained under `"Integral Promotion" on cppreference.com
-<https://en.cppreference.com/w/cpp/language/implicit_conversion>`_.
-This check diagnoses more instances of narrowing than the compiler warning
-`-Wconversion` does. The example below demonstrates this behavior.
-
-.. code-block:: c++
-
- // The following function definition demonstrates usage of arithmetic with
- // integer types smaller than `int` and how the narrowing conversion happens
- // implicitly.
- void computation(short argument1, short argument2) {
- // Arithmetic written by humans:
- short result = argument1 + argument2;
- // Arithmetic actually performed by C++:
- short result = static_cast<short>(static_cast<int>(argument1) + static_cast<int>(argument2));
- }
-
- void recommended_resolution(short argument1, short argument2) {
- short result = argument1 + argument2;
- // ^ warning: narrowing conversion from 'int' to signed type 'short' is implementation-defined
-
- // The cppcoreguidelines recommend to resolve this issue by using the GSL
- // in one of two ways. Either by a cast that throws if a loss of precision
- // would occur.
- short result = gsl::narrow<short>(argument1 + argument2);
- // Or it can be resolved without checking the result risking invalid results.
- short result = gsl::narrow_cast<short>(argument1 + argument2);
-
- // A classical `static_cast` will silence the warning as well if the GSL
- // is not available.
- short result = static_cast<short>(argument1 + argument2);
- }
-
-Options
--------
-
-.. option:: WarnOnIntegerNarrowingConversion
-
- When `true`, the check will warn on narrowing integer conversion
- (e.g. ``int`` to ``size_t``). `true` by default.
-
-.. option:: WarnOnIntegerToFloatingPointNarrowingConversion
+- an integer to a narrower integer (e.g. `char` to `unsigned char`)
+ if WarnOnIntegerNarrowingConversion Option is set,
+- an integer to a narrower floating-point (e.g. `uint64_t` to `float`)
+ if WarnOnIntegerToFloatingPointNarrowingConversion Option is set,
+- a floating-point to an integer (e.g. `double` to `int`),
+- a floating-point to a narrower floating-point (e.g. `double` to `float`)
+ if WarnOnFloatingPointNarrowingConversion Option is set.
- When `true`, the check will warn on narrowing integer to floating-point
- conversion (e.g. ``size_t`` to ``double``). `true` by default.
-
-.. option:: WarnOnFloatingPointNarrowingConversion
-
- When `true`, the check will warn on narrowing floating point conversion
- (e.g. ``double`` to ``float``). `true` by default.
-
-.. option:: WarnWithinTemplateInstantiation
-
- When `true`, the check will warn on narrowing conversions within template
- instantiations. `false` by default.
-
-.. option:: WarnOnEquivalentBitWidth
-
- When `true`, the check will warn on narrowing conversions that arise from
- casting between types of equivalent bit width. (e.g.
- `int n = uint(0);` or `long long n = double(0);`) `true` by default.
-
-.. option:: IgnoreConversionFromTypes
-
- Narrowing conversions from any type in this semicolon-separated list will be
- ignored. This may be useful to weed out commonly occurring, but less commonly
- problematic assignments such as `int n = std::vector<char>().size();` or
- `int n = std::difference(it1, it2);`. The default list is empty, but one
- suggested list for a legacy codebase would be
- `size_t;ptrdiff_t;size_type;difference_type`.
-
-.. option:: PedanticMode
+This check will flag:
- When `true`, the check will warn on assigning a floating point constant
- to an integer value even if the floating point value is exactly
- representable in the destination type (e.g. ``int i = 1.0;``).
- `false` by default.
+- All narrowing conversions that are not marked by an explicit cast (c-style
+ or `static_cast`). For example: `int i = 0; i += 0.1;`,
+ `void f(int); f(0.1);`,
+- All applications of binary operators with a narrowing conversions.
+ For example: `int i; i+= 0.1;`.
-FAQ
----
+Arithmetic with smaller integer types than `int` trigger implicit conversions,
+as explained under ["Integral Promotion" on cppreference.com](https://en.cppreference.com/w/cpp/language/implicit_conversion).
+This check diagnoses more instances of narrowing than the compiler warning
+`-Wconversion` does. The example below demonstrates this behavior.
- - What does "narrowing conversion from 'int' to 'float'" mean?
+```c++
+// The following function definition demonstrates usage of arithmetic with
+// integer types smaller than `int` and how the narrowing conversion happens
+// implicitly.
+void computation(short argument1, short argument2) {
+ // Arithmetic written by humans:
+ short result = argument1 + argument2;
+ // Arithmetic actually performed by C++:
+ short result = static_cast<short>(static_cast<int>(argument1) + static_cast<int>(argument2));
+}
+
+void recommended_resolution(short argument1, short argument2) {
+ short result = argument1 + argument2;
+ // ^ warning: narrowing conversion from 'int' to signed type 'short' is implementation-defined
+
+ // The cppcoreguidelines recommend to resolve this issue by using the GSL
+ // in one of two ways. Either by a cast that throws if a loss of precision
+ // would occur.
+ short result = gsl::narrow<short>(argument1 + argument2);
+ // Or it can be resolved without checking the result risking invalid results.
+ short result = gsl::narrow_cast<short>(argument1 + argument2);
+
+ // A classical `static_cast` will silence the warning as well if the GSL
+ // is not available.
+ short result = static_cast<short>(argument1 + argument2);
+}
+```
+
+## Options
+
+```{option} WarnOnIntegerNarrowingConversion
+When `true`, the check will warn on narrowing integer conversion
+(e.g. `int` to `size_t`). `true` by default.
+```
+
+```{option} WarnOnIntegerToFloatingPointNarrowingConversion
+When `true`, the check will warn on narrowing integer to floating-point
+conversion (e.g. `size_t` to `double`). `true` by default.
+```
+
+```{option} WarnOnFloatingPointNarrowingConversion
+When `true`, the check will warn on narrowing floating point conversion
+(e.g. `double` to `float`). `true` by default.
+```
+
+```{option} WarnWithinTemplateInstantiation
+When `true`, the check will warn on narrowing conversions within template
+instantiations. `false` by default.
+```
+
+```{option} WarnOnEquivalentBitWidth
+When `true`, the check will warn on narrowing conversions that arise from
+casting between types of equivalent bit width. (e.g.
+`int n = uint(0);` or `long long n = double(0);`) `true` by default.
+```
+
+```{option} IgnoreConversionFromTypes
+Narrowing conversions from any type in this semicolon-separated list will be
+ignored. This may be useful to weed out commonly occurring, but less commonly
+problematic assignments such as `int n = std::vector<char>().size();` or
+`int n = std::difference(it1, it2);`. The default list is empty, but one
+suggested list for a legacy codebase would be
+`size_t;ptrdiff_t;size_type;difference_type`.
+```
+
+```{option} PedanticMode
+When `true`, the check will warn on assigning a floating point constant
+to an integer value even if the floating point value is exactly
+representable in the destination type (e.g. `int i = 1.0;`).
+`false` by default.
+```
+
+## FAQ
+
+> - What does "narrowing conversion from 'int' to 'float'" mean?
An IEEE754 Floating Point number can represent all integer values in the range
[-2^PrecisionBits, 2^PrecisionBits] where PrecisionBits is the number of bits
in the mantissa.
-For ``float`` this would be [-2^23, 2^23], where ``int`` can represent values
+For `float` this would be [-2^23, 2^23], where `int` can represent values
in the range [-2^31, 2^31-1].
- - What does "implementation-defined" mean?
+> - What does "implementation-defined" mean?
You may have encountered messages like "narrowing conversion from 'unsigned
int' to signed type 'int' is implementation-defined".
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst
index 0ae950d75316e..d96f6b08f7623 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst
@@ -1,18 +1,18 @@
-.. title:: clang-tidy - bugprone-non-zero-enum-to-bool-conversion
+```{title} clang-tidy - bugprone-non-zero-enum-to-bool-conversion
+```
-bugprone-non-zero-enum-to-bool-conversion
-=========================================
+# bugprone-non-zero-enum-to-bool-conversion
-Detect implicit and explicit casts of ``enum`` type into ``bool`` where
-``enum`` type doesn't have a zero-value enumerator. If the ``enum`` is used
-only to hold values equal to its enumerators, then conversion to ``bool`` will
-always result in ``true`` value. This can lead to unnecessary code that reduces
+Detect implicit and explicit casts of `enum` type into `bool` where
+`enum` type doesn't have a zero-value enumerator. If the `enum` is used
+only to hold values equal to its enumerators, then conversion to `bool` will
+always result in `true` value. This can lead to unnecessary code that reduces
readability and maintainability and can result in bugs.
-May produce false positives if the ``enum`` is used to store other values
+May produce false positives if the `enum` is used to store other values
(used as a bit-mask or zero-initialized on purpose). To deal with them,
-``// NOLINT`` or casting first to the underlying type before casting to
-``bool`` can be used.
+`// NOLINT` or casting first to the underlying type before casting to
+`bool` can be used.
It is important to note that this check will not generate warnings if the
definition of the enumeration type is not available.
@@ -22,32 +22,30 @@ Overall, this check serves to improve code quality and readability by
identifying and flagging instances where implicit or explicit casts from
enumeration types to boolean could cause potential issues.
-Example
--------
+## Example
-.. code-block:: c++
+```c++
+enum EStatus {
+ OK = 1,
+ NOT_OK,
+ UNKNOWN
+};
- enum EStatus {
- OK = 1,
- NOT_OK,
- UNKNOWN
- };
-
- void process(EStatus status) {
- if (!status) {
- // this true-branch won't be executed
- return;
- }
- // proceed with "valid data"
+void process(EStatus status) {
+ if (!status) {
+ // this true-branch won't be executed
+ return;
}
-
-Options
--------
-
-.. option:: EnumIgnoreList
-
- Option is used to ignore certain enum types when checking for
- implicit/explicit casts to bool. It accepts a semicolon-separated list of
- (fully qualified) enum type names or regular expressions that match the enum
- type names.
- The default value is an empty string, which means no enums will be ignored.
+ // proceed with "valid data"
+}
+```
+
+## Options
+
+```{option} EnumIgnoreList
+Option is used to ignore certain enum types when checking for
+implicit/explicit casts to bool. It accepts a semicolon-separated list of
+(fully qualified) enum type names or regular expressions that match the enum
+type names.
+The default value is an empty string, which means no enums will be ignored.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/nondeterministic-pointer-iteration-order.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/nondeterministic-pointer-iteration-order.rst
index 33cf79eccae6b..347a818c2c853 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/nondeterministic-pointer-iteration-order.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/nondeterministic-pointer-iteration-order.rst
@@ -1,30 +1,30 @@
-.. title:: clang-tidy - bugprone-nondeterministic-pointer-iteration-order
+```{title} clang-tidy - bugprone-nondeterministic-pointer-iteration-order
+```
-bugprone-nondeterministic-pointer-iteration-order
-=================================================
+# bugprone-nondeterministic-pointer-iteration-order
Finds nondeterministic usages of pointers in unordered containers.
One canonical example is iteration across a container of pointers.
-.. code-block:: c++
-
- {
- int a = 1, b = 2;
- std::unordered_set<int *> UnorderedPtrSet = {&a, &b};
- for (auto i : UnorderedPtrSet)
- f(i);
- }
+```c++
+{
+ int a = 1, b = 2;
+ std::unordered_set<int *> UnorderedPtrSet = {&a, &b};
+ for (auto i : UnorderedPtrSet)
+ f(i);
+}
+```
Another such example is sorting a container of pointers.
-.. code-block:: c++
-
- {
- int a = 1, b = 2;
- std::vector<int *> VectorOfPtr = {&a, &b};
- std::sort(VectorOfPtr.begin(), VectorOfPtr.end());
- }
+```c++
+{
+ int a = 1, b = 2;
+ std::vector<int *> VectorOfPtr = {&a, &b};
+ std::sort(VectorOfPtr.begin(), VectorOfPtr.end());
+}
+```
Iteration of a containers of pointers may present the order of different
pointers differently across different runs of a program. In some cases this
@@ -35,12 +35,10 @@ This check only detects range-based for loops over unordered sets and maps. It
also detects calls sorting-like algorithms on containers holding pointers.
Other similar usages will not be found and are false negatives.
+## Limitations
-Limitations
------------
-
-* This check currently does not check if a nondeterministic iteration order is
+- This check currently does not check if a nondeterministic iteration order is
likely to be a mistake, and instead marks all such iterations as bugprone.
-* std::reference_wrapper is not considered yet.
-* Only for loops are considered, other iterators can be included in
+- std::reference_wrapper is not considered yet.
+- Only for loops are considered, other iterators can be included in
improvements.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst
index db86e94063ec0..e5f76285ce998 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst
@@ -1,134 +1,125 @@
-.. title:: clang-tidy - bugprone-not-null-terminated-result
+```{title} clang-tidy - bugprone-not-null-terminated-result
+```
-bugprone-not-null-terminated-result
-===================================
+# bugprone-not-null-terminated-result
Finds function calls where it is possible to cause a not null-terminated
-result. Usually the proper length of a string is ``strlen(src) + 1`` or equal
+result. Usually the proper length of a string is `strlen(src) + 1` or equal
length of this expression, because the null terminator needs an extra space.
Without the null terminator it can result in undefined behavior when the
string is read.
-The following and their respective ``wchar_t`` based functions are checked:
+The following and their respective `wchar_t` based functions are checked:
-``memcpy``, ``memcpy_s``, ``memchr``, ``memmove``, ``memmove_s``,
-``strerror_s``, ``strncmp``, ``strxfrm``
+`memcpy`, `memcpy_s`, `memchr`, `memmove`, `memmove_s`,
+`strerror_s`, `strncmp`, `strxfrm`
The following is a real-world example where the programmer forgot to increase
-the passed third argument, which is ``size_t length``. That is why the length
+the passed third argument, which is `size_t length`. That is why the length
of the allocated memory is not enough to hold the null terminator.
-.. code-block:: c
-
- static char *stringCpy(const std::string &str) {
- char *result = reinterpret_cast<char *>(malloc(str.size()));
- memcpy(result, str.data(), str.size());
- return result;
- }
+```c
+static char *stringCpy(const std::string &str) {
+ char *result = reinterpret_cast<char *>(malloc(str.size()));
+ memcpy(result, str.data(), str.size());
+ return result;
+}
+```
In addition to issuing warnings, fix-it rewrites all the necessary code.
It also tries to adjust the capacity of the destination array:
-.. code-block:: c
-
- static char *stringCpy(const std::string &str) {
- char *result = reinterpret_cast<char *>(malloc(str.size() + 1));
- strcpy(result, str.data());
- return result;
- }
+```c
+static char *stringCpy(const std::string &str) {
+ char *result = reinterpret_cast<char *>(malloc(str.size() + 1));
+ strcpy(result, str.data());
+ return result;
+}
+```
Note: It cannot guarantee to rewrite every of the path-sensitive memory
allocations.
-.. _MemcpyTransformation:
+(memcpytransformation)=
-Transformation rules of 'memcpy()'
-----------------------------------
+## Transformation rules of 'memcpy()'
-It is possible to rewrite the ``memcpy()`` and ``memcpy_s()`` calls as the
-following four functions: ``strcpy()``, ``strncpy()``, ``strcpy_s()``,
-``strncpy_s()``, where the latter two are the safer versions of the former two.
-It rewrites the ``wchar_t`` based memory handler functions respectively.
+It is possible to rewrite the `memcpy()` and `memcpy_s()` calls as the
+following four functions: `strcpy()`, `strncpy()`, `strcpy_s()`,
+`strncpy_s()`, where the latter two are the safer versions of the former two.
+It rewrites the `wchar_t` based memory handler functions respectively.
-Rewrite based on the destination array
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+### Rewrite based on the destination array
- If copy to the destination array cannot overflow [1] the new function should
- be the older copy function (ending with ``cpy``), because it is more
+ be the older copy function (ending with `cpy`), because it is more
efficient than the safe version.
-
- If copy to the destination array can overflow [1] and
- :option:`WantToUseSafeFunctions` is set to `true` and it is possible to
+ {option}`WantToUseSafeFunctions` is set to `true` and it is
+ possible to
obtain the capacity of the destination array then the new function could be
- the safe version (ending with ``cpy_s``).
-
+ the safe version (ending with `cpy_s`).
- If the new function is could be safe version and C++ files are analyzed and
- the destination array is plain ``char``/``wchar_t`` without ``un/signed``
+ the destination array is plain `char`/`wchar_t` without `un/signed`
then the length of the destination array can be omitted.
-
- If the new function is could be safe version and the destination array is
- ``un/signed`` it needs to be casted to plain ``char *``/``wchar_t *``.
+ `un/signed` it needs to be casted to plain `char *`/`wchar_t *`.
[1] It is possible to overflow:
- - If the capacity of the destination array is unknown.
- - If the given length is equal to the destination array's capacity.
-Rewrite based on the length of the source string
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+- If the capacity of the destination array is unknown.
+- If the given length is equal to the destination array's capacity.
-- If the given length is ``strlen(source)`` or equal length of this expression
- then the new function should be the older copy function (ending with
- ``cpy``), as it is more efficient than the safe version (ending with
- ``cpy_s``).
+### Rewrite based on the length of the source string
+- If the given length is `strlen(source)` or equal length of this expression
+ then the new function should be the older copy function (ending with
+ `cpy`), as it is more efficient than the safe version (ending with
+ `cpy_s`).
- Otherwise we assume that the programmer wanted to copy 'N' characters, so the
- new function is ``ncpy``-like which copies 'N' characters.
+ new function is `ncpy`-like which copies 'N' characters.
-Transformations with 'strlen()' or equal length of this expression
-------------------------------------------------------------------
+## Transformations with 'strlen()' or equal length of this expression
-It transforms the ``wchar_t`` based memory and string handler functions
-respectively (where only ``strerror_s`` does not have ``wchar_t`` based alias).
+It transforms the `wchar_t` based memory and string handler functions
+respectively (where only `strerror_s` does not have `wchar_t` based alias).
-Memory handler functions
-^^^^^^^^^^^^^^^^^^^^^^^^
+### Memory handler functions
-``memcpy``
+`memcpy`
Please visit the
-:ref:`Transformation rules of 'memcpy()'<MemcpyTransformation>` section.
+{ref}`Transformation rules of 'memcpy()'<MemcpyTransformation>` section.
-``memchr``
+`memchr`
Usually there is a C-style cast and it is needed to be removed, because the
-new function ``strchr``'s return type is correct. The given length is going
+new function `strchr`'s return type is correct. The given length is going
to be removed.
-``memmove``
-If safe functions are available the new function is ``memmove_s``, which has
+`memmove`
+If safe functions are available the new function is `memmove_s`, which has
a new second argument which is the length of the destination array, it is
adjusted, and the length of the source string is incremented by one.
If safe functions are not available the given length is incremented by one.
-``memmove_s``
+`memmove_s`
The given length is incremented by one.
-String handler functions
-^^^^^^^^^^^^^^^^^^^^^^^^
+### String handler functions
-``strerror_s``
+`strerror_s`
The given length is incremented by one.
-``strncmp``
-If the third argument is the first or the second argument's ``length + 1``
-it has to be truncated without the ``+ 1`` operation.
+`strncmp`
+If the third argument is the first or the second argument's `length + 1`
+it has to be truncated without the `+ 1` operation.
-``strxfrm``
+`strxfrm`
The given length is incremented by one.
-Options
--------
-
-.. option:: WantToUseSafeFunctions
+## Options
- The value `true` specifies that the target environment is considered to
- implement '_s' suffixed memory and string handler functions which are safer
- than older versions (e.g. 'memcpy_s()'). The default value is `true`.
+```{option} WantToUseSafeFunctions
+The value `true` specifies that the target environment is considered to
+implement '\_s' suffixed memory and string handler functions which are safer
+than older versions (e.g. 'memcpy_s()'). The default value is `true`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.rst
index f139650301c24..9b9828207b3b3 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-optional-value-conversion
+```{title} clang-tidy - bugprone-optional-value-conversion
+```
-bugprone-optional-value-conversion
-==================================
+# bugprone-optional-value-conversion
Detects potentially unintentional and redundant conversions where a value is
extracted from an optional-like type and then used to create a new instance of
@@ -14,63 +14,62 @@ unexpected behavior.
To illustrate, consider the following problematic code snippet:
-.. code-block:: c++
+```c++
+#include <optional>
- #include <optional>
+void print(std::optional<int>);
- void print(std::optional<int>);
+int main()
+{
+ std::optional<int> opt;
+ // ...
- int main()
- {
- std::optional<int> opt;
- // ...
+ // Unintentional conversion from std::optional<int> to int and back to
+ // std::optional<int>:
+ print(opt.value());
- // Unintentional conversion from std::optional<int> to int and back to
- // std::optional<int>:
- print(opt.value());
+ // ...
+}
+```
- // ...
- }
-
-A better approach would be to directly pass ``opt`` to the ``print`` function
+A better approach would be to directly pass `opt` to the `print` function
without extracting its value:
-.. code-block:: c++
-
- #include <optional>
+```c++
+#include <optional>
- void print(std::optional<int>);
+void print(std::optional<int>);
- int main()
- {
- std::optional<int> opt;
- // ...
+int main()
+{
+ std::optional<int> opt;
+ // ...
- // Proposed code: Directly pass the std::optional<int> to the print
- // function.
- print(opt);
+ // Proposed code: Directly pass the std::optional<int> to the print
+ // function.
+ print(opt);
- // ...
- }
+ // ...
+}
+```
-By passing ``opt`` directly to the print function, unnecessary conversions are
+By passing `opt` directly to the print function, unnecessary conversions are
avoided, and potential unintended behavior or exceptions are minimized.
-Value extraction using ``operator *`` is matched by default.
-The support for non-standard optional types such as ``boost::optional`` or
-``absl::optional`` may be limited.
-
-Options:
---------
-
-.. option:: OptionalTypes
+Value extraction using `operator *` is matched by default.
+The support for non-standard optional types such as `boost::optional` or
+`absl::optional` may be limited.
- Semicolon-separated list of (fully qualified) optional type names or regular
- expressions that match the optional types.
- Default value is `::std::optional;::absl::optional;::boost::optional`.
+## Options:
-.. option:: ValueMethods
+```{option} OptionalTypes
+Semicolon-separated list of (fully qualified) optional type names or regular
+expressions that match the optional types.
+Default value is `::std::optional;::absl::optional;::boost::optional`.
+```
- Semicolon-separated list of (fully qualified) method names or regular
- expressions that match the methods.
- Default value is `::value$;::get$`.
+```{option} ValueMethods
+Semicolon-separated list of (fully qualified) method names or regular
+expressions that match the methods.
+Default value is `::value$;::get$`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.rst
index 6412607971306..68772f6e5c83f 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.rst
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-pointer-arithmetic-on-polymorphic-object
+```{title} clang-tidy - bugprone-pointer-arithmetic-on-polymorphic-object
+```
-bugprone-pointer-arithmetic-on-polymorphic-object
-=================================================
+# bugprone-pointer-arithmetic-on-polymorphic-object
Finds pointer arithmetic performed on classes that contain a virtual function.
@@ -16,53 +16,50 @@ derived object.
Example:
-.. code-block:: c++
+```c++
+struct Base {
+ virtual ~Base();
+ int i;
+};
- struct Base {
- virtual ~Base();
- int i;
- };
+struct Derived : public Base {};
- struct Derived : public Base {};
+void foo(Base* b) {
+ b += 1;
+ // warning: pointer arithmetic on class that declares a virtual function can
+ // result in undefined behavior if the dynamic type differs from the
+ // pointer type
+}
- void foo(Base* b) {
- b += 1;
- // warning: pointer arithmetic on class that declares a virtual function can
- // result in undefined behavior if the dynamic type differs from the
- // pointer type
- }
+int bar(const Derived d[]) {
+ return d[1].i; // warning due to pointer arithmetic on polymorphic object
+}
- int bar(const Derived d[]) {
- return d[1].i; // warning due to pointer arithmetic on polymorphic object
- }
+// Making Derived final suppresses the warning
+struct FinalDerived final : public Base {};
- // Making Derived final suppresses the warning
- struct FinalDerived final : public Base {};
+int baz(const FinalDerived d[]) {
+ return d[1].i; // no warning as FinalDerived is final
+}
+```
- int baz(const FinalDerived d[]) {
- return d[1].i; // no warning as FinalDerived is final
- }
+## Options
-Options
--------
+````{option} IgnoreInheritedVirtualFunctions
+When `true`, objects that only inherit a virtual function are not checked.
+Classes that do not declare a new virtual function are excluded
+by default, as they make up the majority of false positives.
+Default: `false`.
-.. option:: IgnoreInheritedVirtualFunctions
+```c++
+void bar(Base b[], Derived d[]) {
+ b += 1; // warning, as Base declares a virtual destructor
+ d += 1; // warning only if IgnoreVirtualDeclarationsOnly is set to false
+}
+```
+````
- When `true`, objects that only inherit a virtual function are not checked.
- Classes that do not declare a new virtual function are excluded
- by default, as they make up the majority of false positives.
- Default: `false`.
-
- .. code-block:: c++
-
- void bar(Base b[], Derived d[]) {
- b += 1; // warning, as Base declares a virtual destructor
- d += 1; // warning only if IgnoreVirtualDeclarationsOnly is set to false
- }
-
-References
-----------
+## References
This check corresponds to the SEI Cert rule
-`CTR56-CPP. Do not use pointer arithmetic on polymorphic objects
-<https://cmu-sei.github.io/secure-coding-standards/sei-cert-cpp-coding-standard/rules/containers-ctr/ctr56-cpp/>`_.
+[CTR56-CPP. Do not use pointer arithmetic on polymorphic objects](https://cmu-sei.github.io/secure-coding-standards/sei-cert-cpp-coding-standard/rules/containers-ctr/ctr56-cpp/).
More information about the cfe-commits
mailing list