[clang-tidy][docs][NFC] Enforce 80 characters limit (4/4) #168049
Merged
+363
−222
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
|
@llvm/pr-subscribers-clang-tidy Author: mitchell (zeyi2) ChangesFix documentation in This is part of the codebase cleanup described in #167098 Patch is 64.24 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/168049.diff 33 Files Affected:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst b/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst
index ef9f391f31fa7..9658246b21d2a 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst b/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst
index 10752ef3b1cb8..e5d174c33315d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst
index 4bb023cdabc8b..389409412e251 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst
+++ b/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::
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst
index b5a1386d2166e..39c4e0aa2716b 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst
+++ b/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)
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst
index 60b9c82e9f926..53f9453afcfae 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst
index 8233ea13f94e0..dc69f203aac45 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst
+++ b/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,
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst
index 2901d721706c8..e6d25d9dabf09 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst
index 0e9d5476e7016..00581b10334ff 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst
index ab43c2fa58d4c..7ba3a1dd976d8 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst
+++ b/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
-------
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst
index 31463c2b65dd3..fdde5522a56e2 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst
+++ b/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>``:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst
index 913b20f93b438..e21dedfacd5b1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst b/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst
index 9f5b263f7f671..120d360ab5841 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst b/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst
index a4eff16cbab14..4b2ef6ef1fbea 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst
+++ b/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 `...
[truncated]
|
Member
|
@llvm/pr-subscribers-clang-tools-extra Author: mitchell (zeyi2) ChangesFix documentation in This is part of the codebase cleanup described in #167098 Patch is 64.24 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/168049.diff 33 Files Affected:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst b/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst
index ef9f391f31fa7..9658246b21d2a 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/mpi/buffer-deref.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst b/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst
index 10752ef3b1cb8..e5d174c33315d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/mpi/type-mismatch.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst
index 4bb023cdabc8b..389409412e251 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/forbidden-subclassing.rst
+++ b/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::
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst
index b5a1386d2166e..39c4e0aa2716b 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/nsdate-formatter.rst
+++ b/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)
diff --git a/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst b/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst
index 60b9c82e9f926..53f9453afcfae 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/objc/property-declaration.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst
index 8233ea13f94e0..dc69f203aac45 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/no-int-to-ptr.rst
+++ b/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,
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst
index 2901d721706c8..e6d25d9dabf09 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-swap.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst
index 0e9d5476e7016..00581b10334ff 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/performance/unnecessary-copy-initialization.rst
+++ b/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:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst
index ab43c2fa58d4c..7ba3a1dd976d8 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/simd-intrinsics.rst
+++ b/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
-------
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst
index 31463c2b65dd3..fdde5522a56e2 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/std-allocator-const.rst
+++ b/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>``:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst b/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst
index 913b20f93b438..e21dedfacd5b1 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/portability/template-virtual-member-function.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst b/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst
index 9f5b263f7f671..120d360ab5841 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/container-contains.rst
+++ b/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.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst b/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst
index a4eff16cbab14..4b2ef6ef1fbea 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability/container-data-pointer.rst
+++ b/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 `...
[truncated]
|
Member
Author
|
This is the final part of existing documentation cleanup. After this PR gets merged, I'll try implement a lit check that uses doc8 to verify new/modified documentation :) |
Contributor
You probably won't be able to do that because you basically don't have What you can do instead is install This can be discuss it further in issue. |
EugeneZelenko
requested review from
HerrCai0907,
carlosgalvezp,
localspook and
vbvictor
EugeneZelenko
approved these changes
Nov 14, 2025
vbvictor
reviewed
Nov 18, 2025
Comment on lines
59
to
60
| * | **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 |
Contributor
There was a problem hiding this comment.
The separated line was as long as previous, why change?
| (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) |
Contributor
There was a problem hiding this comment.
This was actually 80-char long, can we leave it as is?
|
|
||
| * | **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 |
Contributor
There was a problem hiding this comment.
Can we fill up to 80 char (and elswhere in this file)
| (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) |
Contributor
There was a problem hiding this comment.
less than 80 (check other please)
Comment on lines
79
to
80
| of ``struct X``, the conditional return ``if (x) return true; | ||
| return false;`` becomes ``return static_cast<bool>(x);`` |
Contributor
There was a problem hiding this comment.
Can we make "conditional return" in full line on next line (without separation)
Member
Author
There was a problem hiding this comment.
Thanks for reviewing, I've fixed the problems as requested :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix documentation in
mpi,objc,openmp,performance,portability,readabilityandzircon.This is part of the codebase cleanup described in #167098