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

Fix documentation in `mpi`, `objc`, `openmp`, `performance`,
`portability`, `readability` and `zircon`.

This is part of the codebase cleanup described in
#167098

Author: zeyi2

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,93 @@
 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`;
+   * | **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)
 
-   * | **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)
 
-   * | **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)
 
-   * | **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>``: