[llvm-branch-commits] [clang-tools-extra] [clang-tidy][docs] Rewrite bugprone check docs to Markdown [4/4] (PR #214427)

[via llvm-branch-commits]

llvmorg-github-actions[bot] wrote:


<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-clang-tidy

@llvm/pr-subscribers-clang-tools-extra

Author: Zeyi Xu (zeyi2)

<details>
<summary>Changes</summary>

<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>

---

Patch is 123.41 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/214427.diff


22 Files Affected:

- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.md (+28-28) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.md (+34-36) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.md (+45-46) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-stringview-data-usage.md (+41-42) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.md (+11-11) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/switch-missing-default-case.md (+40-38) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.md (+237-235) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/too-small-loop-variable.md (+35-36) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.md (+199-222) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-string-to-number-conversion.md (+18-20) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/undefined-memory-manipulation.md (+17-17) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-code-paths.md (+45-46) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-exception-at-new.md (+40-41) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-self-assignment.md (+89-90) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unintended-char-ostream-output.md (+42-43) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unique-ptr-array-mismatch.md (+23-24) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.md (+172-173) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-to-allow-exceptions.md (+22-23) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-local-non-trivial-variable.md (+52-50) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-raii.md (+10-10) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-return-value.md (+55-56) 
- (modified) clang-tools-extra/docs/clang-tidy/checks/bugprone/use-after-move.md (+158-168) 


``````````diff
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.md
index 9885d9c2ae9ff..5ccd94ec71b90 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.md
@@ -1,45 +1,45 @@
-.. title:: clang-tidy - bugprone-suspicious-realloc-usage
+```{title} clang-tidy - bugprone-suspicious-realloc-usage
+```
 
-bugprone-suspicious-realloc-usage
-=================================
+# bugprone-suspicious-realloc-usage
 
-This check finds usages of ``realloc`` where the return value is assigned to
+This check finds usages of `realloc` where the return value is assigned to
 the same expression as passed to the first argument:
-``p = realloc(p, size);``
-The problem with this construct is that if ``realloc`` fails it returns a
+`p = realloc(p, size);`
+The problem with this construct is that if `realloc` fails it returns a
 null pointer but does not deallocate the original memory. If no other variable
 is pointing to it, the original memory block is not available any more for the
-program to use or free. In either case ``p = realloc(p, size);`` indicates bad
-coding style and can be replaced by ``q = realloc(p, size);``.
+program to use or free. In either case `p = realloc(p, size);` indicates bad
+coding style and can be replaced by `q = realloc(p, size);`.
 
-The pointer expression (used at ``realloc``) can be a variable or a field
+The pointer expression (used at `realloc`) can be a variable or a field
 member of a data structure, but can not contain function calls or unresolved
 types.
 
 In obvious cases when the pointer used at realloc is assigned to another
-variable before the ``realloc`` call, no warning is emitted. This happens only
-if a simple expression in form of ``q = p`` or ``void *q = p`` is found in the
-same function where ``p = realloc(p, ...)`` is found. The assignment has to be
+variable before the `realloc` call, no warning is emitted. This happens only
+if a simple expression in form of `q = p` or `void *q = p` is found in the
+same function where `p = realloc(p, ...)` is found. The assignment has to be
 before the call to realloc (but otherwise at any place) in the same function.
-This suppression works only if ``p`` is a single variable.
+This suppression works only if `p` is a single variable.
 
 Examples:
 
-.. code-block:: c++
+```c++
+struct A {
+  void *p;
+};
 
-  struct A {
-    void *p;
-  };
+A &getA();
 
-  A &getA();
+void foo(void *p, A *a, int new_size) {
+  p = realloc(p, new_size); // warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
+  a->p = realloc(a->p, new_size); // warning: 'a->p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
+  getA().p = realloc(getA().p, new_size); // no warning
+}
 
-  void foo(void *p, A *a, int new_size) {
-    p = realloc(p, new_size); // warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
-    a->p = realloc(a->p, new_size); // warning: 'a->p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
-    getA().p = realloc(getA().p, new_size); // no warning
-  }
-
-  void foo1(void *p, int new_size) {
-    void *p1 = p;
-    p = realloc(p, new_size); // no warning
-  }
+void foo1(void *p, int new_size) {
+  void *p1 = p;
+  p = realloc(p, new_size); // no warning
+}
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.md
index 56e23d77024cb..f2a015d7b3d11 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.md
@@ -1,39 +1,37 @@
-.. title:: clang-tidy - bugprone-suspicious-semicolon
+```{title} clang-tidy - bugprone-suspicious-semicolon
+```
 
-bugprone-suspicious-semicolon
-=============================
+# bugprone-suspicious-semicolon
 
 Finds most instances of stray semicolons that unexpectedly alter the meaning of
-the code. More specifically, it looks for ``if``, ``while``, ``for`` and
-``for-range`` statements whose body is a single semicolon, and then analyzes
+the code. More specifically, it looks for `if`, `while`, `for` and
+`for-range` statements whose body is a single semicolon, and then analyzes
 the context of the code (e.g. indentation) in an attempt to determine whether
 that is intentional.
 
-.. code-block:: c++
+```c++
+if (x < y);
+{
+  x++;
+}
+```
 
-    if (x < y);
-    {
-      x++;
-    }
-
-Here the body of the ``if`` statement consists of only the semicolon at the end
+Here the body of the `if` statement consists of only the semicolon at the end
 of the first line, and `x` will be incremented regardless of the condition.
 
-
-.. code-block:: c++
-
-    while ((line = readLine(file)) != NULL);
-      processLine(line);
+```c++
+while ((line = readLine(file)) != NULL);
+  processLine(line);
+```
 
 As a result of this code, `processLine()` will only be called once, when the
-``while`` loop with the empty body exits with ``line == NULL``. The indentation
+`while` loop with the empty body exits with `line == NULL`. The indentation
 of the code indicates the intention of the programmer.
 
-
-.. code-block:: c++
-
-    if (x >= y);
-    x -= y;
+```c++
+if (x >= y);
+x -= y;
+```
 
 While the indentation does not imply any nesting, there is simply no valid
 reason to have an `if` statement with an empty body (but it can make sense for
@@ -43,10 +41,10 @@ To solve the issue remove the stray semicolon or in case the empty body is
 intentional, reflect this using code indentation or put the semicolon in a new
 line. For example:
 
-.. code-block:: c++
-
-    while (readWhitespace());
-      Token t = readNextToken();
+```c++
+while (readWhitespace());
+  Token t = readNextToken();
+```
 
 Here the second line is indented in a way that suggests that it is meant to be
 the body of the `while` loop - whose body is in fact empty, because of the
@@ -54,19 +52,19 @@ semicolon at the end of the first line.
 
 Either remove the indentation from the second line:
 
-.. code-block:: c++
-
-    while (readWhitespace());
-    Token t = readNextToken();
+```c++
+while (readWhitespace());
+Token t = readNextToken();
+```
 
 ... or move the semicolon from the end of the first line to a new line:
 
-.. code-block:: c++
-
-    while (readWhitespace())
-      ;
+```c++
+while (readWhitespace())
+  ;
 
-      Token t = readNextToken();
+  Token t = readNextToken();
+```
 
 In this case the check will assume that you know what you are doing, and will
 not raise a warning.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.md
index 973b70393faf0..b2d80f4be93de 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.md
@@ -1,64 +1,63 @@
-.. title:: clang-tidy - bugprone-suspicious-string-compare
+```{title} clang-tidy - bugprone-suspicious-string-compare
+```
 
-bugprone-suspicious-string-compare
-==================================
+# bugprone-suspicious-string-compare
 
 Find suspicious usage of runtime string comparison functions.
 This check is valid in C and C++.
 
 Checks for calls with implicit comparator and proposed to explicitly add it.
 
-.. code-block:: c++
+```c++
+if (strcmp(...))       // Implicitly compare to zero
+if (!strcmp(...))      // Won't warn
+if (strcmp(...) != 0)  // Won't warn
+```
 
-    if (strcmp(...))       // Implicitly compare to zero
-    if (!strcmp(...))      // Won't warn
-    if (strcmp(...) != 0)  // Won't warn
-
-Checks that compare function results (i.e., ``strcmp``) are compared to valid
+Checks that compare function results (i.e., `strcmp`) are compared to valid
 constant. The resulting value is
 
-.. code::
-
-    <  0    when lower than,
-    >  0    when greater than,
-    == 0    when equals.
+```
+<  0    when lower than,
+>  0    when greater than,
+== 0    when equals.
+```
 
 A common mistake is to compare the result to `1` or `-1`.
 
-.. code-block:: c++
-
-    if (strcmp(...) == -1)  // Incorrect usage of the returned value.
+```c++
+if (strcmp(...) == -1)  // Incorrect usage of the returned value.
+```
 
 Additionally, the check warns if the results value is implicitly cast to a
 *suspicious* non-integer type. It's happening when the returned value is
 used in a wrong context.
 
-.. code-block:: c++
-
-    if (strcmp(...) < 0.)  // Incorrect usage of the returned value.
-
-Options
--------
-
-.. option:: WarnOnImplicitComparison
-
-   When `true`, the check will warn on implicit comparison. `true` by default.
-
-.. option:: WarnOnLogicalNotComparison
-
-   When `true`, the check will warn on logical not comparison. `false` by default.
-
-.. option:: StringCompareLikeFunctions
-
-   A string specifying the comma-separated names of the extra string comparison
-   functions. Default is an empty string.
-   The check will detect the following string comparison functions:
-   `__builtin_memcmp`, `__builtin_strcasecmp`, `__builtin_strcmp`,
-   `__builtin_strncasecmp`, `__builtin_strncmp`, `_mbscmp`, `_mbscmp_l`,
-   `_mbsicmp`, `_mbsicmp_l`, `_mbsnbcmp`, `_mbsnbcmp_l`, `_mbsnbicmp`,
-   `_mbsnbicmp_l`, `_mbsncmp`, `_mbsncmp_l`, `_mbsnicmp`, `_mbsnicmp_l`,
-   `_memicmp`, `_memicmp_l`, `_stricmp`, `_stricmp_l`, `_strnicmp`,
-   `_strnicmp_l`, `_wcsicmp`, `_wcsicmp_l`, `_wcsnicmp`, `_wcsnicmp_l`,
-   `lstrcmp`, `lstrcmpi`, `memcmp`, `memicmp`, `strcasecmp`, `strcmp`,
-   `strcmpi`, `stricmp`, `strncasecmp`, `strncmp`, `strnicmp`, `wcscasecmp`,
-   `wcscmp`, `wcsicmp`, `wcsncmp`, `wcsnicmp`, `wmemcmp`.
+```c++
+if (strcmp(...) < 0.)  // Incorrect usage of the returned value.
+```
+
+## Options
+
+```{option} WarnOnImplicitComparison
+When `true`, the check will warn on implicit comparison. `true` by default.
+```
+
+```{option} WarnOnLogicalNotComparison
+When `true`, the check will warn on logical not comparison. `false` by default.
+```
+
+```{option} StringCompareLikeFunctions
+A string specifying the comma-separated names of the extra string comparison
+functions. Default is an empty string.
+The check will detect the following string comparison functions:
+`__builtin_memcmp`, `__builtin_strcasecmp`, `__builtin_strcmp`,
+`__builtin_strncasecmp`, `__builtin_strncmp`, `_mbscmp`, `_mbscmp_l`,
+`_mbsicmp`, `_mbsicmp_l`, `_mbsnbcmp`, `_mbsnbcmp_l`, `_mbsnbicmp`,
+`_mbsnbicmp_l`, `_mbsncmp`, `_mbsncmp_l`, `_mbsnicmp`, `_mbsnicmp_l`,
+`_memicmp`, `_memicmp_l`, `_stricmp`, `_stricmp_l`, `_strnicmp`,
+`_strnicmp_l`, `_wcsicmp`, `_wcsicmp_l`, `_wcsnicmp`, `_wcsnicmp_l`,
+`lstrcmp`, `lstrcmpi`, `memcmp`, `memicmp`, `strcasecmp`, `strcmp`,
+`strcmpi`, `stricmp`, `strncasecmp`, `strncmp`, `strnicmp`, `wcscasecmp`,
+`wcscmp`, `wcsicmp`, `wcsncmp`, `wcsnicmp`, `wmemcmp`.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-stringview-data-usage.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-stringview-data-usage.md
index de10da21e8442..2ead896eb7c80 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-stringview-data-usage.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-stringview-data-usage.md
@@ -1,61 +1,60 @@
-.. title:: clang-tidy - bugprone-suspicious-stringview-data-usage
+```{title} clang-tidy - bugprone-suspicious-stringview-data-usage
+```
 
-bugprone-suspicious-stringview-data-usage
-=========================================
+# bugprone-suspicious-stringview-data-usage
 
-Identifies suspicious usages of ``std::string_view::data()`` that could lead to
+Identifies suspicious usages of `std::string_view::data()` that could lead to
 reading out-of-bounds data due to inadequate or incorrect string null
 termination.
 
-It warns when the result of ``data()`` is passed to a constructor or function
-without also passing the corresponding result of ``size()`` or ``length()``
+It warns when the result of `data()` is passed to a constructor or function
+without also passing the corresponding result of `size()` or `length()`
 member function. Such usage can lead to unintended behavior, particularly when
-assuming the data pointed to by ``data()`` is null-terminated.
+assuming the data pointed to by `data()` is null-terminated.
 
-The absence of a ``c_str()`` method in ``std::string_view`` often leads
-developers to use ``data()`` as a substitute, especially when interfacing with
-C APIs that expect null-terminated strings. However, since ``data()`` does not
+The absence of a `c_str()` method in `std::string_view` often leads
+developers to use `data()` as a substitute, especially when interfacing with
+C APIs that expect null-terminated strings. However, since `data()` does not
 guarantee null termination, this can result in unintended behavior if the API
 relies on proper null termination for correct string interpretation.
 
 In today's programming landscape, this scenario can occur when implicitly
-converting an ``std::string_view`` to an ``std::string``. Since the constructor
-in ``std::string`` designed for string-view-like objects is ``explicit``,
-attempting to pass an ``std::string_view`` to a function expecting an
-``std::string`` will result in a compilation error. As a workaround, developers
-may be tempted to utilize the ``.data()`` method to achieve compilation,
+converting an `std::string_view` to an `std::string`. Since the constructor
+in `std::string` designed for string-view-like objects is `explicit`,
+attempting to pass an `std::string_view` to a function expecting an
+`std::string` will result in a compilation error. As a workaround, developers
+may be tempted to utilize the `.data()` method to achieve compilation,
 introducing potential risks.
 
 For instance:
 
-.. code-block:: c++
+```c++
+void printString(const std::string& str) {
+  std::cout << "String: " << str << std::endl;
+}
 
-  void printString(const std::string& str) {
-    std::cout << "String: " << str << std::endl;
-  }
+void something(std::string_view sv) {
+  printString(sv.data());
+}
+```
 
-  void something(std::string_view sv) {
-    printString(sv.data());
-  }
-
-In this example, directly passing ``sv`` to the ``printString`` function would
-lead to a compilation error due to the explicit nature of the ``std::string``
-constructor. Consequently, developers might opt for ``sv.data()`` to resolve the
+In this example, directly passing `sv` to the `printString` function would
+lead to a compilation error due to the explicit nature of the `std::string`
+constructor. Consequently, developers might opt for `sv.data()` to resolve the
 compilation error, albeit introducing potential hazards as discussed.
 
-Options
--------
-
-.. option:: StringViewTypes
-
-  Option allows users to specify custom string view-like types for analysis. It
-  accepts a semicolon-separated list of type names or regular expressions
-  matching these types. Default value is:
-  `::std::basic_string_view;::llvm::StringRef`.
-
-.. option:: AllowedCallees
-
-  Specifies methods, functions, or classes where the result of ``.data()`` is
-  passed to. Allows to exclude such calls from the analysis. Accepts a
-  semicolon-separated list of names or regular expressions matching these
-  entities. Default value is: empty string.
+## Options
+
+```{option} StringViewTypes
+Option allows users to specify custom string view-like types for analysis. It
+accepts a semicolon-separated list of type names or regular expressions
+matching these types. Default value is:
+`::std::basic_string_view;::llvm::StringRef`.
+```
+
+```{option} AllowedCallees
+Specifies methods, functions, or classes where the result of `.data()` is
+passed to. Allows to exclude such calls from the analysis. Accepts a
+semicolon-separated list of names or regular expressions matching these
+entities. Default value is: empty string.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.md
index e798b67937170..f912ed3deedc1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.md
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-swapped-arguments
+```{title} clang-tidy - bugprone-swapped-arguments
+```
 
-bugprone-swapped-arguments
-==========================
+# bugprone-swapped-arguments
 
 Finds potentially swapped arguments by examining implicit conversions.
 It analyzes the types of the arguments being passed to a function and compares
@@ -9,15 +9,15 @@ them to the expected types of the corresponding parameters. If there is a
 mismatch or an implicit conversion that indicates a potential swap, a warning
 is raised.
 
-.. code-block:: c++
+```c++
+void printNumbers(int a, float b);
 
-  void printNumbers(int a, float b);
-
-  int main() {
-    // Swapped arguments: float passed as int, int as float)
-    printNumbers(10.0f, 5);
-    return 0;
-  }
+int main() {
+  // Swapped arguments: float passed as int, int as float)
+  printNumbers(10.0f, 5);
+  return 0;
+}
+```
 
 Covers a wide range of implicit conversions, including:
 - User-defined conversions
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/switch-missing-default-case.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/switch-missing-default-case.md
index 0f0e549091f46..e83a726b4e4e7 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/switch-missing-default-case.md
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/switch-missing-default-case.md
@@ -1,7 +1,7 @@
-.. title:: clang-tidy - bugprone-switch-missing-default-case
+```{title} clang-tidy - bugprone-switch-missing-default-case
+```
 
-bugprone-switch-missing-default-case
-====================================
+# bugprone-switch-missing-default-case
 
 Ensures that switch statements without default cases are flagged, focuses only
 on covering cases with non-enums where the compiler may not issue warnings.
@@ -19,38 +19,40 @@ values, reducing the risk of program errors and unexpected behavior.
 
 Example:
 
-.. code-block:: c++
-
-  // Example 1:
-  // warning: switching on non-enum value without default case may not cover all cases
-  switch (i) {
-  case 0:
-    break;
-  }
-
-  // Example 2:
-  enum E { eE1 };
-  E e = eE1;
-  switch (e) { // no-warning
-  case eE1:
-    break;
-  }
-
-  // Example 3:
-  int i = 0;
-  switch (i) { // no-warning
-  case 0:
-    break;
-  default:
-    break;
-  }
-
-.. note::
-   Enum types are already covered by compiler warnings (comes under -Wswitch)
-   when a switch statement does not handle all enum values. This check focuses
-   on non-enum types where the compiler warnings may not be present.
-
-.. seealso::
-   The `CppCoreGuideline ES.79 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#res-default>`_
-   provide guidelines on switch statements, including the recommendation to
-   always provide a default case.
+```c++
+// Example 1:
+// warning: switching on non-enum value without default case may not cover all cases
+switch (i) {
+case 0:
+  break;
+}
+
+// Example 2:
+enum E { eE1 };
+E e = eE1;
+switch (e) { // no-warning
+case eE1:
+  break;
+}
+
+// Example 3:
+int i = 0;
+switch (i) { // no-warning
+case 0:
+  break;
+default:
+  break;
+}
+```
+
+```{note}
+Enum types are already covered by compiler warnings (comes under -Wswitch)
+when a switch statement does not handle all enum values. This check focuses
+on non-enum types where the compiler warnings may not be present.
+```
+
+```{seealso}
+The [CppCoreGuideline ES.79](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#res-default)
+provide guidelines on switch statements, including the recommendation to
+always provide a default case.
+```
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.md
index 5ac5e3240d7a6..1a3a12db3ed98 100644
--- a/clang-tools-extra/doc...
[truncated]

``````````

</details>


https://github.com/llvm/llvm-project/pull/214427