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

clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst

@@ -5,9 +5,10 @@ mpi-buffer-deref
 
 This check verifies if a buffer passed to an MPI (Message Passing Interface)
 function is sufficiently dereferenced. Buffers should be passed as a single
-pointer or array. As MPI function signatures specify ``void *`` for their buffer
-types, insufficiently dereferenced buffers can be passed, like for example as
-double pointers or multidimensional arrays, without a compiler warning emitted.
+pointer or array. As MPI function signatures specify ``void *`` for their
+buffer types, insufficiently dereferenced buffers can be passed, like for
+example as double pointers or multidimensional arrays, without a compiler
+warning emitted.
 
 Examples:
 

clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst

@@ -3,10 +3,11 @@
 mpi-type-mismatch
 =================
 
-This check verifies if buffer type and MPI (Message Passing Interface) datatype
-pairs match for used MPI functions. All MPI datatypes defined by the MPI
-standard (3.1) are verified by this check. User defined typedefs, custom MPI
-datatypes and null pointer constants are skipped, in the course of verification.
+This check verifies if buffer type and MPI (Message Passing Interface)
+datatype pairs match for used MPI functions. All MPI datatypes defined
+by the MPI standard (3.1) are verified by this check. User defined typedefs,
+custom MPI datatypes and null pointer constants are skipped, in the course
+of verification.
 
 Example:
 

clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst

@@ -3,11 +3,11 @@
 objc-forbidden-subclassing
 ==========================
 
-Finds Objective-C classes which are subclasses of classes which are not designed
-to be subclassed.
+Finds Objective-C classes which are subclasses of classes which are
+not designed to be subclassed.
 
-By default, includes a list of Objective-C classes which are publicly documented
-as not supporting subclassing.
+By default, includes a list of Objective-C classes which are publicly
+documented as not supporting subclassing.
 
 .. note::
 

clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst

@@ -3,71 +3,97 @@
 objc-nsdate-formatter
 =====================
 
-When ``NSDateFormatter`` is used to convert an ``NSDate`` type to a ``String`` type, the user
-can specify a custom format string. Certain format specifiers are undesirable
-despite being legal. See http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns for all legal date patterns.
+When ``NSDateFormatter`` is used to convert an ``NSDate`` type to a ``String``
+type, the user can specify a custom format string. Certain format specifiers
+are undesirable despite being legal.
+See http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns
+for all legal date patterns.
 
-This checker reports as warnings the following string patterns in a date format specifier:
+This checker reports as warnings the following string patterns in a date
+format specifier:
 
-#. yyyy + ww : Calendar year specified with week of a week year (unless YYYY is also specified).
+#. yyyy + ww : Calendar year specified with week of a week year
+   (unless YYYY is also specified).
 
-   * | **Example 1:** Input Date: `29 December 2014` ; Format String: `yyyy-ww`;
-     | Output string: `2014-01` (Wrong because it’s not the first week of 2014)
+   * | **Example 1:** Input Date: `29 December 2014` ;
+     | Format String: `yyyy-ww`;
+     | Output string: `2014-01` (Wrong because it’s not
+     | the first week of 2014)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `dd-MM-yyyy (ww-YYYY)`;
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `dd-MM-yyyy (ww-YYYY)`;
      | Output string: `29-12-2014 (01-2015)` (This is correct)
 
 #. F without ee/EE : Numeric day of week in a month without actual day.
 
    * | **Example:** Input Date: `29 December 2014` ; Format String: `F-MM`;
-     | Output string: `5-12` (Wrong because it reads as *5th ___ of Dec* in English)
+     | Output string: `5-12` (Wrong because it reads as
+     | *5th ___ of Dec* in English)
 
 #. F without MM : Numeric day of week in a month without month.
 
    * | **Example:** Input Date: `29 December 2014` ; Format String: `F-EE`
-     | Output string: `5-Mon` (Wrong because it reads as *5th Mon of ___* in English)
+     | Output string: `5-Mon` (Wrong because it reads as
+     | *5th Mon of ___* in English)
 
 #. WW without MM : Week of the month without the month.
 
    * | **Example:** Input Date: `29 December 2014` ; Format String: `WW-yyyy`
-     | Output string: `05-2014` (Wrong because it reads as *5th Week of ___* in English)
+     | Output string: `05-2014` (Wrong because it reads as
+     | *5th Week of ___* in English)
 
-#. YYYY + QQ : Week year specified with quarter of normal year (unless yyyy is also specified).
+#. YYYY + QQ : Week year specified with quarter of normal year
+   (unless yyyy is also specified).
 
    * | **Example 1:** Input Date: `29 December 2014` ; Format String: `YYYY-QQ`
-     | Output string: `2015-04` (Wrong because it’s not the 4th quarter of 2015)
+     | Output string: `2015-04` (Wrong because it’s not
+     | the 4th quarter of 2015)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `ww-YYYY (QQ-yyyy)`
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `ww-YYYY (QQ-yyyy)`
      | Output string: `01-2015 (04-2014)` (This is correct)
 
-#. YYYY + MM :  Week year specified with Month of a calendar year (unless yyyy is also specified).
+#. YYYY + MM :  Week year specified with Month of a calendar year
+   (unless yyyy is also specified).
 
    * | **Example 1:** Input Date: `29 December 2014` ; Format String: `YYYY-MM`
-     | Output string: `2015-12` (Wrong because it’s not the 12th month of 2015)
+     | Output string: `2015-12` (Wrong because it’s not
+     | the 12th month of 2015)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `ww-YYYY (MM-yyyy)`
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `ww-YYYY (MM-yyyy)`
      | Output string: `01-2015 (12-2014)` (This is correct)
 
-#. YYYY + DD : Week year with day of a calendar year (unless yyyy is also specified).
+#. YYYY + DD : Week year with day of a calendar year
+   (unless yyyy is also specified).
 
    * | **Example 1:** Input Date: `29 December 2014` ; Format String: `YYYY-DD`
-     | Output string: `2015-363` (Wrong because it’s not the 363rd day of 2015)
+     | Output string: `2015-363` (Wrong because it’s not
+     | the 363rd day of 2015)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `ww-YYYY (DD-yyyy)`
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `ww-YYYY (DD-yyyy)`
      | Output string: `01-2015 (363-2014)` (This is correct)
 
-#. YYYY + WW : Week year with week of a calendar year (unless yyyy is also specified).
+#. YYYY + WW : Week year with week of a calendar year
+   (unless yyyy is also specified).
 
    * | **Example 1:** Input Date: `29 December 2014` ; Format String: `YYYY-WW`
-     | Output string: `2015-05` (Wrong because it’s not the 5th week of 2015)
+     | Output string: `2015-05` (Wrong because it’s not
+     | the 5th week of 2015)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `ww-YYYY (WW-MM-yyyy)`
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `ww-YYYY (WW-MM-yyyy)`
      | Output string: `01-2015 (05-12-2014)` (This is correct)
 
-#. YYYY + F : Week year with day of week in a calendar month (unless yyyy is also specified).
+#. YYYY + F : Week year with day of week in a calendar month
+   (unless yyyy is also specified).
 
-   * | **Example 1:** Input Date: `29 December 2014` ; Format String: `YYYY-ww-F-EE`
-     | Output string: `2015-01-5-Mon` (Wrong because it’s not the 5th Monday of January in 2015)
+   * | **Example 1:** Input Date: `29 December 2014` ;
+     | Format String: `YYYY-ww-F-EE`
+     | Output string: `2015-01-5-Mon` (Wrong because it’s not
+     | the 5th Monday of January in 2015)
 
-   * | **Example 2:** Input Date: `29 December 2014` ; Format String: `ww-YYYY (F-EE-MM-yyyy)`
+   * | **Example 2:** Input Date: `29 December 2014` ;
+     | Format String: `ww-YYYY (F-EE-MM-yyyy)`
      | Output string: `01-2015 (5-Mon-12-2014)` (This is correct)

clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst

@@ -23,8 +23,8 @@ The check will only fix 'CamelCase' to 'camelCase'. In some other cases we will
 only provide warning messages since the property name could be complicated.
 Users will need to come up with a proper name by their own.
 
-This check also accepts special acronyms as prefixes or suffixes. Such prefixes or suffixes
-will suppress the Lower Camel Case check according to the guide:
+This check also accepts special acronyms as prefixes or suffixes. Such prefixes
+or suffixes will suppress the Lower Camel Case check according to the guide:
 https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingBasics.html#//apple_ref/doc/uid/20001281-1002931-BBCFHEAB
 
 For a full list of well-known acronyms:

clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst

@@ -7,8 +7,8 @@ Diagnoses every integer to pointer cast.
 
 While casting an (integral) pointer to an integer is obvious - you just get
 the integral value of the pointer, casting an integer to an (integral) pointer
-is deceivingly different. While you will get a pointer with that integral value,
-if you got that integral value via a pointer-to-integer cast originally,
+is deceivingly different. While you will get a pointer with that integral
+value, if you got that integral value via a pointer-to-integer cast originally,
 the new pointer will lack the provenance information from the original pointer.
 
 So while (integral) pointer to integer casts are effectively no-ops,

clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst

@@ -3,11 +3,11 @@
 performance-noexcept-swap
 =========================
 
-The check flags user-defined swap and iter_swap functions not marked with ``noexcept`` or
-marked with ``noexcept(expr)`` where ``expr`` evaluates to ``false``
-(but is not a ``false`` literal itself).
+The check flags user-defined swap and iter_swap functions not marked with
+``noexcept`` or marked with ``noexcept(expr)`` where ``expr`` evaluates to
+``false`` (but is not a ``false`` literal itself).
 
-When a swap or iter_swap function is marked as ``noexcept``, it assures the compiler that
-no exceptions will be thrown during the swapping of two objects, which allows
-the compiler to perform certain optimizations such as omitting exception
-handling code.
+When a swap or iter_swap function is marked as ``noexcept``, it assures the
+compiler that no exceptions will be thrown during the swapping of two objects,
+which allows the compiler to perform certain optimizations such as omitting
+exception handling code.

clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst

@@ -9,8 +9,8 @@ const reference.
 
 The check is only applied if it is safe to replace the copy by a const
 reference. This is the case when the variable is const qualified or when it is
-only used as a const, i.e. only const methods or operators are invoked on it, or
-it is used as const reference or value argument in constructors or function
+only used as a const, i.e. only const methods or operators are invoked on it,
+or it is used as const reference or value argument in constructors or function
 calls.
 
 Example:

clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst

@@ -19,18 +19,18 @@ objects.
 Otherwise, it just complains the intrinsics are non-portable (and there are
 `P0214`_ alternatives).
 
-Many architectures provide SIMD operations (e.g. x86 SSE/AVX, Power AltiVec/VSX,
-ARM NEON). It is common that SIMD code implementing the same algorithm, is
-written in multiple target-dispatching pieces to optimize for different
-architectures or micro-architectures.
+Many architectures provide SIMD operations (e.g. x86 SSE/AVX, Power
+AltiVec/VSX, ARM NEON). It is common that SIMD code implementing the same
+algorithm, is written in multiple target-dispatching pieces to optimize for
+different architectures or micro-architectures.
 
 The C++ standard proposal `P0214`_ and its extensions cover many common SIMD
 operations. By migrating from target-dependent intrinsics to `P0214`_
-operations, the SIMD code can be simplified and pieces for different targets can
-be unified.
+operations, the SIMD code can be simplified and pieces for different targets
+can be unified.
 
-Refer to `P0214`_ for introduction and motivation for the data-parallel standard
-library.
+Refer to `P0214`_ for introduction and motivation for the data-parallel
+standard library.
 
 Options
 -------

clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst

@@ -9,11 +9,11 @@ elements). These are not allowed in standard C++, and should usually be
 
 Per C++ ``[allocator.requirements.general]``: "T is any cv-unqualified object
 type", ``std::allocator<const T>`` is undefined. Many standard containers use
-``std::allocator`` by default and therefore their ``const T`` instantiations are
-undefined.
+``std::allocator`` by default and therefore their ``const T`` instantiations
+are undefined.
 
-libc++ defines ``std::allocator<const T>`` as an extension which will be removed
-in the future.
+libc++ defines ``std::allocator<const T>`` as an extension which will be
+removed in the future.
 
 libstdc++ and MSVC do not support ``std::allocator<const T>``:
 

clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst

@@ -3,16 +3,17 @@
 portability-template-virtual-member-function
 ============================================
 
-Finds cases when an uninstantiated virtual member function in a template class causes
-cross-compiler incompatibility.
+Finds cases when an uninstantiated virtual member function in a template class
+causes cross-compiler incompatibility.
 
-Upon instantiating a template class, non-virtual member functions don't have to be
-instantiated unless they are used. Virtual member function instantiation on the other hand
-is unspecified and depends on the implementation of the compiler.
+Upon instantiating a template class, non-virtual member functions don't have
+to be instantiated unless they are used. Virtual member function instantiation
+on the other hand is unspecified and depends on the implementation of the
+compiler.
 
-In the following snippets the virtual member function is not instantiated by GCC and Clang,
-but it is instantiated by MSVC, so while the snippet is accepted by the former compilers,
-it is rejected by the latter.
+In the following snippets the virtual member function is not instantiated by
+GCC and Clang, but it is instantiated by MSVC, so while the snippet is accepted
+by the former compilers, it is rejected by the latter.
 
 .. code:: c++
 
@@ -32,6 +33,7 @@ it is rejected by the latter.
         return 0;
     }
 
-Cross-platform projects that need to support MSVC on Windows might see compiler errors
-because certain virtual member functions are instantiated, which are not instantiated
-by other compilers on other platforms. This check highlights such virtual member functions.
+Cross-platform projects that need to support MSVC on Windows might see compiler
+errors because certain virtual member functions are instantiated, which are not
+instantiated by other compilers on other platforms. This check highlights such
+virtual member functions.

clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst

@@ -30,5 +30,5 @@ Initial expression                      Result
 
 This check will apply to any class that has a ``contains`` method, notably
 including ``std::set``, ``std::unordered_set``, ``std::map``, and
-``std::unordered_map`` as of C++20, and ``std::string`` and ``std::string_view``
-as of C++23.
+``std::unordered_map`` as of C++20, and ``std::string`` and
+``std::string_view`` as of C++23.

clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst

@@ -6,11 +6,11 @@ readability-container-data-pointer
 Finds cases where code could use ``data()`` rather than the address of the
 element at index 0 in a container. This pattern is commonly used to materialize
 a pointer to the backing data of a container. ``std::vector`` and
-``std::string`` provide a ``data()`` accessor to retrieve the data pointer which
-should be preferred.
+``std::string`` provide a ``data()`` accessor to retrieve the data pointer
+which should be preferred.
 
-This also ensures that in the case that the container is empty, the data pointer
-access does not perform an errant memory access.
+This also ensures that in the case that the container is empty, the data
+pointer access does not perform an errant memory access.
 
 Options
 -------

clang-tools-extra/docs/clang-tidy/checks/readability/convert-member-functions-to-static.rst

@@ -10,5 +10,6 @@ After applying modifications as suggested by the check, running the check again
 might find more opportunities to mark member functions ``static``.
 
 After making a member function ``static``, you might want to run the check
-:doc:`readability-static-accessed-through-instance <../readability/static-accessed-through-instance>` to replace calls like
+:doc:`readability-static-accessed-through-instance
+<../readability/static-accessed-through-instance>` to replace calls like
 ``Instance.method()`` by ``Class::method()``.

clang-tools-extra/docs/clang-tidy/checks/readability/delete-null-pointer.rst

@@ -3,7 +3,8 @@
 readability-delete-null-pointer
 ===============================
 
-Checks the ``if`` statements where a pointer's existence is checked and then deletes the pointer.
+Checks the ``if`` statements where a pointer's existence is checked and
+then deletes the pointer.
 The check is unnecessary as deleting a null pointer has no effect.
 
 .. code:: c++

clang-tools-extra/docs/clang-tidy/checks/readability/else-after-return.rst

@@ -9,7 +9,8 @@ Early exit is one of the suggested enforcements of that. Please do not use
 ``else`` or ``else if`` after something that interrupts control flow - like
 ``return``, ``break``, ``continue``, ``throw``.
 
-The following piece of code illustrates how the check works. This piece of code:
+The following piece of code illustrates how the check works.
+This piece of code:
 
 .. code-block:: c++
 

clang-tools-extra/docs/clang-tidy/checks/readability/function-cognitive-complexity.rst

@@ -68,8 +68,8 @@ Nesting level
 ^^^^^^^^^^^^^
 
 While by itself the nesting level does not change the function's Cognitive
-Complexity metric, it is tracked, and is used by the next, third building block.
-The following structures increase the nesting level (by `1`):
+Complexity metric, it is tracked, and is used by the next, third building
+block. The following structures increase the nesting level (by `1`):
 
 * Conditional operators:
 

clang-tools-extra/docs/clang-tidy/checks/readability/identifier-length.rst

@@ -16,7 +16,8 @@ The following options are described below:
  - :option:`MinimumVariableNameLength`, :option:`IgnoredVariableNames`
  - :option:`MinimumParameterNameLength`, :option:`IgnoredParameterNames`
  - :option:`MinimumLoopCounterNameLength`, :option:`IgnoredLoopCounterNames`
- - :option:`MinimumExceptionNameLength`, :option:`IgnoredExceptionVariableNames`
+ - :option:`MinimumExceptionNameLength`,
+   :option:`IgnoredExceptionVariableNames`
 
 .. option:: MinimumVariableNameLength