[clang-tidy][docs][NFC] Enforce 80 characters limit (3/N)

clang-tools-extra/docs/clang-tidy/checks/hicpp/braces-around-statements.rst

@@ -6,6 +6,8 @@ hicpp-braces-around-statements
 ==============================
 
 The `hicpp-braces-around-statements` check is an alias, please see
-:doc:`readability-braces-around-statements <../readability/braces-around-statements>`
+:doc:`readability-braces-around-statements
+<../readability/braces-around-statements>`
 for more information.
-It enforces the `rule 6.1.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/statements>`_.
+It enforces the `rule 6.1.1
+<https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/statements>`_.

clang-tools-extra/docs/clang-tidy/checks/hicpp/explicit-conversions.rst

@@ -5,13 +5,21 @@
 hicpp-explicit-conversions
 ==========================
 
-This check is an alias for :doc:`google-explicit-constructor <../google/explicit-constructor>`.
-Used to enforce parts of `rule 5.4.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard-expressions>`_.
-This check will enforce that constructors and conversion operators are marked `explicit`.
-Other forms of casting checks are implemented in other places.
-The following checks can be used to check for more forms of casting:
+This check is an alias for
+:doc:`google-explicit-constructor <../google/explicit-constructor>`.
 
-- :doc:`cppcoreguidelines-pro-type-static-cast-downcast <../cppcoreguidelines/pro-type-static-cast-downcast>`
-- :doc:`cppcoreguidelines-pro-type-reinterpret-cast <../cppcoreguidelines/pro-type-reinterpret-cast>`
-- :doc:`cppcoreguidelines-pro-type-const-cast <../cppcoreguidelines/pro-type-const-cast>`
-- :doc:`cppcoreguidelines-pro-type-cstyle-cast <../cppcoreguidelines/pro-type-cstyle-cast>`
+Used to enforce parts of `rule 5.4.1
+<https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard-expressions>`_.
+This check will enforce that constructors and conversion operators are
+marked ``explicit``. Other forms of casting checks are implemented in
+other places. The following checks can be used to check for more forms
+of casting:
+
+- :doc:`cppcoreguidelines-pro-type-static-cast-downcast
+  <../cppcoreguidelines/pro-type-static-cast-downcast>`
+- :doc:`cppcoreguidelines-pro-type-reinterpret-cast
+  <../cppcoreguidelines/pro-type-reinterpret-cast>`
+- :doc:`cppcoreguidelines-pro-type-const-cast
+  <../cppcoreguidelines/pro-type-const-cast>`
+- :doc:`cppcoreguidelines-pro-type-cstyle-cast
+  <../cppcoreguidelines/pro-type-cstyle-cast>`

clang-tools-extra/docs/clang-tidy/checks/hicpp/function-size.rst

@@ -5,7 +5,8 @@
 hicpp-function-size
 ===================
 
-This check is an alias for :doc:`readability-function-size <../readability/function-size>`.
+This check is an alias for
+:doc:`readability-function-size <../readability/function-size>`.
 Useful to enforce multiple sections on function complexity.
 
 - `rule 8.2.2 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/definitions>`_

clang-tools-extra/docs/clang-tidy/checks/hicpp/ignored-remove-result.rst

@@ -13,7 +13,8 @@ operating over. On completion, they return an iterator to the last valid
 element. In the majority of cases the correct behavior is to use this result as
 the first operand in a call to ``std::erase``.
 
-This check is a subset of :doc:`bugprone-unused-return-value <../bugprone/unused-return-value>`
+This check is a subset of :doc:`bugprone-unused-return-value
+<../bugprone/unused-return-value>`
 and depending on used options it can be superfluous to enable both checks.
 
 Options

clang-tools-extra/docs/clang-tidy/checks/hicpp/invalid-access-moved.rst

@@ -5,6 +5,7 @@
 hicpp-invalid-access-moved
 ==========================
 
-This check is an alias for :doc:`bugprone-use-after-move <../bugprone/use-after-move>`.
+This check is an alias for
+:doc:`bugprone-use-after-move <../bugprone/use-after-move>`.
 
 Implements parts of the `rule 8.4.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/definitions>`_ to check if moved-from objects are accessed.

clang-tools-extra/docs/clang-tidy/checks/hicpp/move-const-arg.rst

@@ -6,5 +6,6 @@ hicpp-move-const-arg
 ====================
 
 The `hicpp-move-const-arg` check is an alias, please see
-:doc:`performance-move-const-arg <../performance/move-const-arg>` for more information.
+:doc:`performance-move-const-arg <../performance/move-const-arg>`
+for more information.
 It enforces the `rule 17.3.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/standard-library>`_.

clang-tools-extra/docs/clang-tidy/checks/hicpp/multiway-paths-covered.rst

@@ -4,15 +4,16 @@ hicpp-multiway-paths-covered
 ============================
 
 This check discovers situations where code paths are not fully-covered.
-It furthermore suggests using ``if`` instead of ``switch`` if the code will be more clear.
+It furthermore suggests using ``if`` instead of ``switch`` if the code
+will be more clear.
 The `rule 6.1.2 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/statements>`_
 and `rule 6.1.4 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/statements>`_
 of the High Integrity C++ Coding Standard are enforced.
 
-``if-else if`` chains that miss a final ``else`` branch might lead to unexpected
-program execution and be the result of a logical error.
-If the missing ``else`` branch is intended you can leave it empty with a clarifying
-comment.
+``if-else if`` chains that miss a final ``else`` branch might lead to
+unexpected program execution and be the result of a logical error.
+If the missing ``else`` branch is intended you can leave it empty with
+a clarifying comment.
 This warning can be noisy on some code bases, so it is disabled by default.
 
 .. code-block:: c++
@@ -28,7 +29,8 @@ This warning can be noisy on some code bases, so it is disabled by default.
      // ...
   }
 
-Similar arguments hold for ``switch`` statements which do not cover all possible code paths.
+Similar arguments hold for ``switch`` statements which do not cover all
+possible code paths.
 
 .. code-block:: c++
 

clang-tools-extra/docs/clang-tidy/checks/hicpp/named-parameter.rst

@@ -5,6 +5,7 @@
 hicpp-named-parameter
 =====================
 
-This check is an alias for :doc:`readability-named-parameter <../readability/named-parameter>`.
+This check is an alias for :doc:`readability-named-parameter
+<../readability/named-parameter>`.
 
 Implements `rule 8.2.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/definitions>`_.

clang-tools-extra/docs/clang-tidy/checks/hicpp/no-array-decay.rst

@@ -6,6 +6,7 @@ hicpp-no-array-decay
 ====================
 
 The `hicpp-no-array-decay` check is an alias, please see
-:doc:`cppcoreguidelines-pro-bounds-array-to-pointer-decay <../cppcoreguidelines/pro-bounds-array-to-pointer-decay>`
+:doc:`cppcoreguidelines-pro-bounds-array-to-pointer-decay
+<../cppcoreguidelines/pro-bounds-array-to-pointer-decay>`
 for more information.
 It enforces the `rule 4.1.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/standard-conversions>`_.

clang-tools-extra/docs/clang-tidy/checks/hicpp/uppercase-literal-suffix.rst

@@ -6,7 +6,8 @@ hicpp-uppercase-literal-suffix
 ==============================
 
 The hicpp-uppercase-literal-suffix check is an alias, please see
-:doc:`readability-uppercase-literal-suffix <../readability/uppercase-literal-suffix>` for more information.
+:doc:`readability-uppercase-literal-suffix
+<../readability/uppercase-literal-suffix>` for more information.
 
 Partially implements `rule 4.2.1 <https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/standard-conversions>`_
 to ensure that the ``U`` suffix is writeln properly.

clang-tools-extra/docs/clang-tidy/checks/linuxkernel/must-check-errs.rst

@@ -4,8 +4,8 @@ linuxkernel-must-check-errs
 ===========================
 
 Checks Linux kernel code to see if it uses the results from the functions in
-``linux/err.h``. Also checks to see if code uses the results from functions that
-directly return a value from one of these error functions.
+``linux/err.h``. Also checks to see if code uses the results from functions
+that directly return a value from one of these error functions.
 
 This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
 ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return

clang-tools-extra/docs/clang-tidy/checks/misc/const-correctness.rst

@@ -4,14 +4,14 @@ misc-const-correctness
 ======================
 
 This check implements detection of local variables which could be declared as
-``const`` but are not. Declaring variables as ``const`` is required or recommended by many
-coding guidelines, such as:
+``const`` but are not. Declaring variables as ``const`` is required or
+recommended by many coding guidelines, such as:
 `ES.25 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es25-declare-an-object-const-or-constexpr-unless-you-want-to-modify-its-value-later-on>`_
 from the C++ Core Guidelines.
 
-Please note that this check's analysis is type-based only. Variables that are not modified
-but used to create a non-const handle that might escape the scope are not diagnosed
-as potential ``const``.
+Please note that this check's analysis is type-based only. Variables that are
+not modified but used to create a non-const handle that might escape the scope
+are not diagnosed as potential ``const``.
 
 .. code-block:: c++
 
@@ -44,8 +44,8 @@ The check can analyze values, pointers and references and pointees:
   int const*const pointer_variable = &potential_const_int; // After transformation, both pointer itself and pointee are supported.
   int last_copy = *pointer_variable;
 
-The automatic code transformation is only applied to variables that are declared in single
-declarations. You may want to prepare your code base with
+The automatic code transformation is only applied to variables that are
+declared in single declarations. You may want to prepare your code base with
 :doc:`readability-isolate-declaration <../readability/isolate-declaration>` first.
 
 Note that there is the check
@@ -58,10 +58,11 @@ Limitations
 
 The check does not run on `C` code.
 
-The check will not analyze templated variables or variables that are instantiation dependent.
-Different instantiations can result in different ``const`` correctness properties and in general it
-is not possible to find all instantiations of a template. The template might be used differently in
-an independent translation unit.
+The check will not analyze templated variables or variables that are
+instantiation dependent. Different instantiations can result in
+different ``const`` correctness properties and in general it is not
+possible to find all instantiations of a template. The template might
+be used differently in an independent translation unit.
 
 Options
 -------

clang-tools-extra/docs/clang-tidy/checks/misc/coroutine-hostile-raii.rst

@@ -7,21 +7,23 @@ Detects when objects of certain hostile RAII types persists across suspension
 points in a coroutine. Such hostile types include scoped-lockable types and
 types belonging to a configurable denylist.
 
-Some objects require that they be destroyed on the same thread that created them.
-Traditionally this requirement was often phrased as "must be a local variable",
-under the assumption that local variables always work this way. However this is
-incorrect with C++20 coroutines, since an intervening ``co_await`` may cause the
-coroutine to suspend and later be resumed on another thread.
-
-The lifetime of an object that requires being destroyed on the same thread must
-not encompass a ``co_await`` or ``co_yield`` point. If you create/destroy an object,
-you must do so without allowing the coroutine to suspend in the meantime.
+Some objects require that they be destroyed on the same thread that created
+them. Traditionally this requirement was often phrased as "must be a local
+variable", under the assumption that local variables always work this way.
+However this is incorrect with C++20 coroutines, since an intervening
+``co_await`` may cause the coroutine to suspend and later be resumed on
+another thread.
+
+The lifetime of an object that requires being destroyed on the same thread
+must not encompass a ``co_await`` or ``co_yield`` point. If you create/destroy
+an object, you must do so without allowing the coroutine to suspend in the
+meantime.
 
 Following types are considered as hostile:
 
- - Scoped-lockable types: A scoped-lockable object persisting across a suspension
-   point is problematic as the lock held by this object could be unlocked by a
-   different thread. This would be undefined behaviour.
+ - Scoped-lockable types: A scoped-lockable object persisting across a
+   suspension point is problematic as the lock held by this object could
+   be unlocked by a different thread. This would be undefined behaviour.
    This includes all types annotated with the ``scoped_lockable`` attribute.
 
  - Types belonging to a configurable denylist.

clang-tools-extra/docs/clang-tidy/checks/misc/header-include-cycle.rst

@@ -47,18 +47,18 @@ quality, and a more maintainable codebase overall. Additionally, by ensuring
 that header files are organized in a way that avoids cyclic dependencies,
 developers can make their code easier to understand and modify over time.
 
-It's worth noting that only user-defined headers their dependencies are analyzed,
-System includes such as standard library headers and third-party library headers
-are excluded. System includes are usually well-designed and free of include
-cycles, and ignoring them helps to focus on potential issues within the
-project's own codebase. This limitation doesn't diminish the ability to detect
-``#include`` cycles within the analyzed code.
+It's worth noting that only user-defined headers their dependencies are
+analyzed, system includes such as standard library headers and third-party
+library headers are excluded. System includes are usually well-designed and
+free of include cycles, and ignoring them helps to focus on potential issues
+within the project's own codebase. This limitation doesn't diminish the
+ability to detect ``#include`` cycles within the analyzed code.
 
 Developers should carefully review any warnings or feedback provided by this
 solution. While the analysis aims to identify and prevent include cycles, there
 may be situations where exceptions or modifications are necessary. It's
-important to exercise judgment and consider the specific context of the codebase
-when making adjustments.
+important to exercise judgment and consider the specific context of the
+codebase when making adjustments.
 
 Options
 -------

clang-tools-extra/docs/clang-tidy/checks/misc/misleading-identifier.rst

@@ -4,8 +4,8 @@ misc-misleading-identifier
 ==========================
 
 Finds identifiers that contain Unicode characters with right-to-left direction,
-which can be confusing as they may change the understanding of a whole statement
-line, as described in `Trojan Source <https://trojansource.codes>`_.
+which can be confusing as they may change the understanding of a whole
+statement line, as described in `Trojan Source <https://trojansource.codes>`_.
 
 An example of such misleading code follows:
 

clang-tools-extra/docs/clang-tidy/checks/misc/no-recursion.rst

@@ -11,7 +11,8 @@ and displays one example of a possible call graph loop (recursion).
 References:
 
 * CERT C++ Coding Standard rule `DCL56-CPP. Avoid cycles during initialization of static objects <https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL56-CPP.+Avoid+cycles+during+initialization+of+static+objects>`_.
-* JPL Institutional Coding Standard for the C Programming Language (JPL DOCID D-60411) rule `2.4 Do not use direct or indirect recursion`.
+* JPL Institutional Coding Standard for the C Programming Language
+  (JPL DOCID D-60411) rule `2.4 Do not use direct or indirect recursion`.
 * OpenCL Specification, Version 1.2 rule `6.9 Restrictions: i. Recursion is not supported. <https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf>`_.
 
 

clang-tools-extra/docs/clang-tidy/checks/misc/override-with-different-visibility.rst

@@ -5,11 +5,12 @@ misc-override-with-different-visibility
 
 Finds virtual function overrides with different visibility than the function
 in the base class. This includes for example if a virtual function declared as
-``private`` is overridden and declared as ``public`` in a subclass. The detected
-change is the modification of visibility resulting from keywords ``public``,
-``protected``, ``private`` at overridden virtual functions. The check applies to
-any normal virtual function and optionally to destructors or operators. Use of
-the ``using`` keyword is not considered as visibility change by this check.
+``private`` is overridden and declared as ``public`` in a subclass. The
+detected change is the modification of visibility resulting from keywords
+``public``, ``protected``, ``private`` at overridden virtual functions. The
+check applies to any normal virtual function and optionally to destructors or
+operators. Use of the ``using`` keyword is not considered as visibility
+change by this check.
 
 
 .. code-block:: c++

clang-tools-extra/docs/clang-tidy/checks/misc/throw-by-value-catch-by-reference.rst

@@ -7,16 +7,16 @@ misc-throw-by-value-catch-by-reference
 
 Finds violations of the rule "Throw by value, catch by reference" presented for
 example in "C++ Coding Standards" by H. Sutter and A. Alexandrescu, as well as
-the CERT C++ Coding Standard rule `ERR61-CPP. Catch exceptions by lvalue reference
-<https://wiki.sei.cmu.edu/confluence/display/cplusplus/ERR61-CPP.+Catch+exceptions+by+lvalue+reference>`_.
+the CERT C++ Coding Standard rule `ERR61-CPP. Catch exceptions by lvalue
+reference <https://wiki.sei.cmu.edu/confluence/display/cplusplus/ERR61-CPP.+Catch+exceptions+by+lvalue+reference>`_.
 
 
 Exceptions:
   * Throwing string literals will not be flagged despite being a pointer. They
     are not susceptible to slicing and the usage of string literals is
     idiomatic.
-  * Catching character pointers (``char``, ``wchar_t``, unicode character types)
-    will not be flagged to allow catching string literals.
+  * Catching character pointers (``char``, ``wchar_t``, unicode character
+    types) will not be flagged to allow catching string literals.
   * Moved named values will not be flagged as not throwing an anonymous
     temporary. In this case we can be sure that the user knows that the object
     can't be accessed outside catch blocks handling the error.

clang-tools-extra/docs/clang-tidy/checks/misc/unused-parameters.rst

@@ -8,9 +8,9 @@ code (e.g. when a different parameter is used instead). The suggested fixes
 either comment parameter name out or remove the parameter completely, if all
 callers of the function are in the same translation unit and can be updated.
 
-The check is similar to the ``-Wunused-parameter`` compiler diagnostic and can be
-used to prepare a codebase to enabling of that diagnostic. By default the check
-is more permissive (see :option:`StrictMode`).
+The check is similar to the `-Wunused-parameter` compiler diagnostic and
+can be used to prepare a codebase to enabling of that diagnostic. By default
+the check is more permissive (see :option:`StrictMode`).
 
 .. code-block:: c++
 

clang-tools-extra/docs/clang-tidy/checks/misc/unused-using-decls.rst

@@ -5,9 +5,10 @@ misc-unused-using-decls
 
 Finds unused ``using`` declarations.
 
-Unused ``using``` declarations in header files will not be diagnosed since these
-using declarations are part of the header's public API. Allowed header file
-extensions can be configured via the global option `HeaderFileExtensions`.
+Unused ``using`` declarations in header files will not be diagnosed
+since these using declarations are part of the header's public API.
+Allowed header file extensions can be configured via the global
+option `HeaderFileExtensions`.
 
 Example:
 

clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst

@@ -8,16 +8,16 @@ that could instead be moved into an anonymous namespace.
 
 Anonymous namespaces are the "superior alternative" according to the C++
 Standard. ``static`` was proposed for deprecation, but later un-deprecated to
-keep C compatibility [1]. ``static`` is an overloaded term with different meanings in
-different contexts, so it can create confusion.
+keep C compatibility [1]. ``static`` is an overloaded term with different
+meanings in different contexts, so it can create confusion.
 
 The following uses of ``static`` will *not* be diagnosed:
 
 * Functions or variables in header files, since anonymous namespaces in headers
-  is considered an antipattern. Allowed header file extensions can be configured
-  via the global option `HeaderFileExtensions`.
-* ``const`` or ``constexpr`` variables, since they already have implicit internal
-  linkage in C++.
+  is considered an antipattern. Allowed header file extensions can be
+  configured via the global option `HeaderFileExtensions`.
+* ``const`` or ``constexpr`` variables, since they already have implicit
+  internal linkage in C++.
 
 Examples:
 

clang-tools-extra/docs/clang-tidy/checks/modernize/avoid-setjmp-longjmp.rst

@@ -3,7 +3,8 @@
 modernize-avoid-setjmp-longjmp
 ==============================
 
-Flags all call expressions involving ``setjmp()`` and ``longjmp()`` in C++ code.
+Flags all call expressions involving ``setjmp()`` and
+``longjmp()`` in C++ code.
 
 Exception handling with ``throw`` and ``catch`` should be used instead.