[clang-tidy][docs][NFC] Enforce 80 characters limit (1/N) #167492
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-tools-extra @llvm/pr-subscribers-clang-tidy Author: mitchell (zeyi2) ChangesFix documentation in This is part of the codebase cleanup described in #167098 Patch is 96.23 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/167492.diff 63 Files Affected:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-addition.rst b/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-addition.rst
index ce2eefd9eea62..e8e3da00212aa 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-addition.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-addition.rst
@@ -3,10 +3,10 @@
abseil-duration-addition
========================
-Check for cases where addition should be performed in the ``absl::Time`` domain.
-When adding two values, and one is known to be an ``absl::Time``, we can infer
-that the other should be interpreted as an ``absl::Duration`` of a similar
-scale, and make that inference explicit.
+Checks for cases where addition should be performed in the ``absl::Time``
+domain. When adding two values, and one is known to be an ``absl::Time``,
+we can infer that the other should be interpreted as an ``absl::Duration``
+of a similar scale, and make that inference explicit.
Examples:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-division.rst b/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-division.rst
index b7c8635600cd5..40c12d464687d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-division.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/duration-division.rst
@@ -4,8 +4,10 @@ abseil-duration-division
========================
``absl::Duration`` arithmetic works like it does with integers. That means that
-division of two ``absl::Duration`` objects returns an ``int64`` with any fractional
-component truncated toward 0. See `this link <https://github.com/abseil/abseil-cpp/blob/29ff6d4860070bf8fcbd39c8805d0c32d56628a3/absl/time/time.h#L137>`_ for more information on arithmetic with ``absl::Duration``.
+division of two ``absl::Duration`` objects returns an ``int64`` with any
+fractional component truncated toward 0.
+See `this link <https://github.com/abseil/abseil-cpp/blob/29ff6d4860070bf8fcbd39c8805d0c32d56628a3/absl/time/time.h#L137>`_
+for more information on arithmetic with ``absl::Duration``.
For example:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/faster-strsplit-delimiter.rst b/clang-tools-extra/docs/clang-tidy/checks/abseil/faster-strsplit-delimiter.rst
index fe9115652b538..b5b79d405bded 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/abseil/faster-strsplit-delimiter.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/faster-strsplit-delimiter.rst
@@ -5,9 +5,9 @@ abseil-faster-strsplit-delimiter
Finds instances of ``absl::StrSplit()`` or ``absl::MaxSplits()`` where the
delimiter is a single character string literal and replaces with a character.
-The check will offer a suggestion to change the string literal into a character.
-It will also catch code using ``absl::ByAnyChar()`` for just a single character
-and will transform that into a single character as well.
+The check will offer a suggestion to change the string literal into a
+character. It will also catch code using ``absl::ByAnyChar()`` for just a
+single character and will transform that into a single character as well.
These changes will give the same result, but using characters rather than
single character string literals is more efficient and readable.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/string-find-str-contains.rst b/clang-tools-extra/docs/clang-tidy/checks/abseil/string-find-str-contains.rst
index 042fbdb3f29a9..418df193d6e0d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/abseil/string-find-str-contains.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/string-find-str-contains.rst
@@ -3,8 +3,8 @@
abseil-string-find-str-contains
===============================
-Finds ``s.find(...) == string::npos`` comparisons (for various string-like types)
-and suggests replacing with ``absl::StrContains()``.
+Finds ``s.find(...) == string::npos`` comparisons (for various string-like
+types) and suggests replacing with ``absl::StrContains()``.
This improves readability and reduces the likelihood of accidentally mixing
``find()`` and ``npos`` from different string-like types.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/abseil/upgrade-duration-conversions.rst b/clang-tools-extra/docs/clang-tidy/checks/abseil/upgrade-duration-conversions.rst
index 24e557d2edc32..3abdd40b1b813 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/abseil/upgrade-duration-conversions.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/abseil/upgrade-duration-conversions.rst
@@ -8,17 +8,17 @@ argument needs an explicit cast to continue compiling after upcoming API
changes.
The operators ``*=``, ``/=``, ``*``, and ``/`` for ``absl::Duration`` currently
-accept an argument of class type that is convertible to an arithmetic type. Such
-a call currently converts the value to an ``int64_t``, even in a case such as
-``std::atomic<float>`` that would result in lossy conversion.
+accept an argument of class type that is convertible to an arithmetic type.
+Such a call currently converts the value to an ``int64_t``, even in a case such
+as ``std::atomic<float>`` that would result in lossy conversion.
Additionally, the ``absl::Duration`` factory functions (``absl::Hours``,
``absl::Minutes``, etc) currently accept an ``int64_t`` or a floating-point
type. Similar to the arithmetic operators, calls with an argument of class type
that is convertible to an arithmetic type go through the ``int64_t`` path.
-These operators and factories will be changed to only accept arithmetic types to
-prevent unintended behavior. After these changes are released, passing an
+These operators and factories will be changed to only accept arithmetic types
+to prevent unintended behavior. After these changes are released, passing an
argument of class type will no longer compile, even if the type is implicitly
convertible to an arithmetic type.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-inotify-init1.rst b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-inotify-init1.rst
index 827598ca7c282..741158964ec10 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-inotify-init1.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-inotify-init1.rst
@@ -3,9 +3,10 @@
android-cloexec-inotify-init1
=============================
-``inotify_init1()`` should include ``IN_CLOEXEC`` in its type argument to avoid the
-file descriptor leakage. Without this flag, an opened sensitive file would
-remain open across a fork+exec to a lower-privileged SELinux domain.
+``inotify_init1()`` should include ``IN_CLOEXEC`` in its type argument
+to avoid the file descriptor leakage. Without this flag, an opened
+sensitive file would remain open across a fork+exec to a
+lower-privileged SELinux domain.
Examples:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe.rst b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe.rst
index b0504e9baeec2..45aba4209a1b7 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe.rst
@@ -3,9 +3,10 @@
android-cloexec-pipe
====================
-This check detects usage of ``pipe()``. Using ``pipe()`` is not recommended, ``pipe2()`` is the
-suggested replacement. The check also adds the O_CLOEXEC flag that marks the file descriptor to
-be closed in child processes. Without this flag a sensitive file descriptor can be leaked to a
+This check detects usage of ``pipe()``. Using ``pipe()`` is not recommended,
+``pipe2()`` is the suggested replacement. The check also adds the O_CLOEXEC
+flag that marks the file descriptor to be closed in child processes.
+Without this flag a sensitive file descriptor can be leaked to a
child process, potentially into a lower-privileged SELinux domain.
Examples:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe2.rst b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe2.rst
index 9fb54bee0d571..7d438dac0f117 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe2.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/android/cloexec-pipe2.rst
@@ -3,8 +3,9 @@
android-cloexec-pipe2
=====================
-This check ensures that pipe2() is called with the O_CLOEXEC flag. The check also
-adds the O_CLOEXEC flag that marks the file descriptor to be closed in child processes.
+This check ensures that pipe2() is called with the O_CLOEXEC flag.
+The check also adds the O_CLOEXEC flag that marks the file descriptor
+to be closed in child processes.
Without this flag a sensitive file descriptor can be leaked to a child process,
potentially into a lower-privileged SELinux domain.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/android/comparison-in-temp-failure-retry.rst b/clang-tools-extra/docs/clang-tidy/checks/android/comparison-in-temp-failure-retry.rst
index 31cc72b0579c4..cf5f43ded38d6 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/android/comparison-in-temp-failure-retry.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/android/comparison-in-temp-failure-retry.rst
@@ -22,8 +22,8 @@ Example buggy usage looks like:
// Do something with cs.
}
-Because TEMP_FAILURE_RETRY will check for whether the result *of the comparison*
-is ``-1``, and retry if so.
+Because TEMP_FAILURE_RETRY will check for whether the result
+*of the comparison* is ``-1``, and retry if so.
If you encounter this, the fix is simple: lift the comparison out of the
``TEMP_FAILURE_RETRY`` argument, like so:
diff --git a/clang-tools-extra/docs/clang-tidy/checks/boost/use-to-string.rst b/clang-tools-extra/docs/clang-tidy/checks/boost/use-to-string.rst
index 8365e80fb95a3..9a5bb888ba861 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/boost/use-to-string.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/boost/use-to-string.rst
@@ -3,9 +3,9 @@
boost-use-to-string
===================
-This check finds conversion from integer type like ``int`` to ``std::string`` or
-``std::wstring`` using ``boost::lexical_cast``, and replace it with calls to
-``std::to_string`` and ``std::to_wstring``.
+This check finds conversion from integer type like ``int`` to
+``std::string`` or ``std::wstring`` using ``boost::lexical_cast``,
+and replace it with calls to ``std::to_string`` and ``std::to_wstring``.
It doesn't replace conversion from floating points despite the ``to_string``
overloads, because it would change the behavior.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
index 691b6e4db096b..6e4b9c786f762 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
@@ -4,11 +4,13 @@ bugprone-assignment-in-if-condition
===================================
Finds assignments within conditions of `if` statements.
-Such assignments are bug-prone because they may have been intended as equality tests.
+Such assignments are bug-prone because they may have been intended as
+equality tests.
-This check finds all assignments within `if` conditions, including ones that are not flagged
-by `-Wparentheses` due to an extra set of parentheses, and including assignments that call
-an overloaded `operator=()`. The identified assignments violate
+This check finds all assignments within `if` conditions, including ones that
+are not flagged by `-Wparentheses` due to an extra set of parentheses, and
+including assignments that call an overloaded `operator=()`. The identified
+assignments violate
`BARR group "Rule 8.2.c" <https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard/statement-rules/if-else-statements>`_.
.. code-block:: c++
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/bitwise-pointer-cast.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/bitwise-pointer-cast.rst
index ac58654421a0a..171e6e6157072 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/bitwise-pointer-cast.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/bitwise-pointer-cast.rst
@@ -31,9 +31,9 @@ not on pointer types:
int x{};
float y = std::bit_cast<float>(x);
-This way, the bytes of the input object are copied into the output object, which
-is much safer. Do note that Undefined Behavior can still occur, if there is no
-value of type ``To`` corresponding to the value representation produced.
+This way, the bytes of the input object are copied into the output object,
+which is much safer. Do note that Undefined Behavior can still occur, if there
+is no value of type ``To`` corresponding to the value representation produced.
Compilers may be able to optimize this copy and generate identical assembly to
the original ``reinterpret_cast`` version.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/capturing-this-in-member-variable.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/capturing-this-in-member-variable.rst
index 1017462b8806b..6a6ad7302566e 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/capturing-this-in-member-variable.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/capturing-this-in-member-variable.rst
@@ -6,11 +6,11 @@ bugprone-capturing-this-in-member-variable
Finds lambda captures that capture the ``this`` pointer and store it as class
members without handle the copy and move constructors and the assignments.
-Capture this in a lambda and store it as a class member is dangerous because the
-lambda can outlive the object it captures. Especially when the object is copied
-or moved, the captured ``this`` pointer will be implicitly propagated to the
-new object. Most of the time, people will believe that the captured ``this``
-pointer points to the new object, which will lead to bugs.
+Capture this in a lambda and store it as a class member is dangerous because
+the lambda can outlive the object it captures. Especially when the object is
+copied or moved, the captured ``this`` pointer will be implicitly propagated
+to the new object. Most of the time, people will believe that the captured
+``this`` pointer points to the new object, which will lead to bugs.
.. code-block:: c++
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/casting-through-void.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/casting-through-void.rst
index 21efda444e2ff..3c0b52abea707 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/casting-through-void.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/casting-through-void.rst
@@ -13,16 +13,19 @@ Two-step type conversions via ``void*`` are discouraged for several reasons.
- These conversions bypass valuable compiler support, erasing warnings related
to pointer alignment. It may violate strict aliasing rule and leading to
undefined behavior.
-- In scenarios involving multiple inheritance, ambiguity and unexpected outcomes
- can arise due to the loss of type information, posing runtime issues.
+- In scenarios involving multiple inheritance, ambiguity and unexpected
+ outcomes can arise due to the loss of type information, posing runtime
+ issues.
-In summary, avoiding two-step type conversions through ``void*`` ensures clearer code,
-maintains essential compiler warnings, and prevents ambiguity and potential runtime
-errors, particularly in complex inheritance scenarios. If such a cast is wanted,
-it shall be done via ``reinterpret_cast``, to express the intent more clearly.
+In summary, avoiding two-step type conversions through ``void*`` ensures
+clearer code, maintains essential compiler warnings, and prevents ambiguity
+and potential runtime errors, particularly in complex inheritance scenarios.
+If such a cast is wanted, it shall be done via ``reinterpret_cast``,
+to express the intent more clearly.
Note: it is expected that, after applying the suggested fix and using
-``reinterpret_cast``, the check :doc:`cppcoreguidelines-pro-type-reinterpret-cast
+``reinterpret_cast``, the check
+:doc:`cppcoreguidelines-pro-type-reinterpret-cast
<../cppcoreguidelines/pro-type-reinterpret-cast>` will emit a warning.
This is intentional: ``reinterpret_cast`` is a dangerous operation that can
easily break the strict aliasing rules when dereferencing the casted pointer,
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
index cc711d60e7fd8..6b2a82f1cfe96 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/compare-pointer-to-member-virtual-function.rst
@@ -3,8 +3,8 @@
bugprone-compare-pointer-to-member-virtual-function
===================================================
-Detects unspecified behavior about equality comparison between pointer to member
-virtual function and anything other than null-pointer-constant.
+Detects unspecified behavior about equality comparison between pointer to
+member virtual function and anything other than null-pointer-constant.
.. code-block:: c++
@@ -47,11 +47,11 @@ becomes particularly challenging when dealing with pointers to pure virtual
functions, as they may not even have a valid address, further complicating
comparisons.
-Instead, it is recommended to utilize the ``typeid`` operator or other appropriate
-mechanisms for comparing objects to ensure robust and predictable behavior in
-your codebase. By heeding this detection and adopting a more reliable comparison
-method, you can mitigate potential issues related to unspecified behavior,
-especially when dealing with pointers to member virtual functions or pure
+Instead, it is recommended to utilize the ``typeid`` operator or other
+appropriate mechanisms for comparing objects to ensure robust and predictable
+behavior in your codebase. By heeding this detection and adopting a more reliable
+comparison method, you can mitigate potential issues related to unspecified
+behavior, especially when dealing with pointers to member virtual functions or pure
virtual functions, thereby improving the overall stability and maintainability
of your code. In scenarios involving pointers to member virtual functions, it's
only advisable to employ ``nullptr`` for comparisons.
@@ -60,6 +60,6 @@ only advisable to employ ``nullptr`` for comparisons.
Limitations
-----------
-Does not analyze values stored in a variable. For variable, only analyze all virtual
-methods in the same ``class`` or ``struct`` and diagnose when assigning a pointer
-to member virtual function to this variable is possible.
+Does not analyze values stored in a variable. For variable, only analyze all
+virtual methods in the same ``class`` or ``struct`` and diagnose when assigning
+a pointer to member virtual function to this variable is possible.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/copy-constructor-mutates-argument.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/copy-constructor-mutates-argument.rst
index 28e5015beeaad..e45a94a0c9c0a 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/copy-constructor-mutates-argument.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/copy-constructor-mutates-argument.rst
@@ -8,4 +8,4 @@ in copy constructors and copy assignment operators.
This check corresponds to the CERT C Coding Standard rule
`OOP58-CPP. Copy operations must not mutate the source object
-<https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP58-CPP.+Copy+operations+must+not+mutate+the+source+object>`_.
\ No newline at end of file
+<https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP58-CPP.+Copy+operations+must+not+mutate+the+source+object>`_.
diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/dangling-handle.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/dangling-handle.rst
index 752b711b4ef54..c25f8c4e7caaa 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/dangling-handle.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/dangling-handle.rst
@@ -4,8 +4,9 @@ bugprone-dangling-handle
====================...
[truncated]
|
vbvictor
approved these changes
Nov 12, 2025
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
abseil,android,altera,boostandbugprone.This is part of the codebase cleanup described in #167098