From 13a8abb7fa3cff7d2ec244de7d0b6e1f87778f42 Mon Sep 17 00:00:00 2001 From: mtx Date: Tue, 11 Nov 2025 19:32:06 +0800 Subject: [PATCH 1/3] [clang-tidy][docs] Enforce 80 characters limit (1/N) --- .../checks/abseil/duration-addition.rst | 8 ++-- .../checks/abseil/duration-division.rst | 6 ++- .../abseil/faster-strsplit-delimiter.rst | 6 +-- .../abseil/string-find-str-contains.rst | 4 +- .../abseil/upgrade-duration-conversions.rst | 10 ++--- .../checks/android/cloexec-inotify-init1.rst | 7 +-- .../checks/android/cloexec-pipe.rst | 7 +-- .../checks/android/cloexec-pipe2.rst | 5 ++- .../comparison-in-temp-failure-retry.rst | 4 +- .../clang-tidy/checks/boost/use-to-string.rst | 6 +-- .../bugprone/assignment-in-if-condition.rst | 10 +++-- .../checks/bugprone/bitwise-pointer-cast.rst | 6 +-- .../capturing-this-in-member-variable.rst | 10 ++--- .../checks/bugprone/casting-through-void.rst | 17 ++++--- ...are-pointer-to-member-virtual-function.rst | 20 ++++----- .../copy-constructor-mutates-argument.rst | 2 +- .../checks/bugprone/dangling-handle.rst | 5 ++- .../derived-method-shadowing-base-method.rst | 7 +-- .../bugprone/dynamic-static-initializers.rst | 16 ++++--- .../bugprone/easily-swappable-parameters.rst | 6 +-- .../checks/bugprone/empty-catch.rst | 8 ++-- .../exception-copy-constructor-throws.rst | 2 +- .../checks/bugprone/exception-escape.rst | 6 +-- .../checks/bugprone/fold-init-type.rst | 11 ++--- .../forward-declaration-namespace.rst | 3 +- .../forwarding-reference-overload.rst | 16 +++---- .../checks/bugprone/inc-dec-in-conditions.rst | 25 ++++++----- .../checks/bugprone/infinite-loop.rst | 8 ++-- .../invalid-enum-default-initialization.rst | 4 +- .../misplaced-operator-in-strlen-in-alloc.rst | 16 +++---- .../multiple-new-in-one-expression.rst | 16 +++---- .../checks/bugprone/narrowing-conversions.rst | 27 ++++++------ .../clang-tidy/checks/bugprone/no-escape.rst | 4 +- .../non-zero-enum-to-bool-conversion.rst | 20 ++++----- .../bugprone/not-null-terminated-result.rst | 22 +++++----- .../checks/bugprone/posix-return.rst | 3 +- .../checks/bugprone/random-generator-seed.rst | 10 ++--- .../bugprone/redundant-branch-condition.rst | 14 +++--- .../return-const-ref-from-parameter.rst | 16 +++---- .../checks/bugprone/signal-handler.rst | 8 ++-- .../checks/bugprone/signed-char-misuse.rst | 34 +++++++------- .../checks/bugprone/sizeof-container.rst | 10 ++--- .../checks/bugprone/sizeof-expression.rst | 6 +-- .../bugprone/std-namespace-modification.rst | 15 ++++--- .../string-literal-with-embedded-nul.rst | 6 +-- .../checks/bugprone/suspicious-enum-usage.rst | 16 +++---- .../bugprone/suspicious-memory-comparison.rst | 6 ++- .../bugprone/suspicious-realloc-usage.rst | 9 ++-- .../checks/bugprone/suspicious-semicolon.rst | 10 ++--- .../bugprone/suspicious-string-compare.rst | 4 +- .../checks/bugprone/swapped-arguments.rst | 8 ++-- .../bugprone/tagged-union-member-count.rst | 44 ++++++++++--------- .../checks/bugprone/throw-keyword-missing.rst | 7 +-- .../throwing-static-initialization.rst | 2 +- .../bugprone/too-small-loop-variable.rst | 12 ++--- .../bugprone/unchecked-optional-access.rst | 15 ++++--- .../unchecked-string-to-number-conversion.rst | 4 +- .../bugprone/unhandled-self-assignment.rst | 13 +++--- .../unintended-char-ostream-output.rst | 29 ++++++------ .../checks/bugprone/unsafe-functions.rst | 15 ++++--- .../checks/bugprone/unused-return-value.rst | 3 +- .../checks/bugprone/use-after-move.rst | 38 ++++++++-------- .../checks/bugprone/virtual-near-miss.rst | 5 ++- 63 files changed, 379 insertions(+), 333 deletions(-) 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 `_ 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 `_ +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`` 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`` 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" `_. .. 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(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 -`_. \ No newline at end of file +`_. 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 ======================== Detect dangling references in value handles like ``std::string_view``. -These dangling references can be a result of constructing handles from temporary -values, where the temporary is destroyed soon after the handle is created. +These dangling references can be a result of constructing handles from +temporary values, where the temporary is destroyed soon after the handle +is created. Examples: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/derived-method-shadowing-base-method.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/derived-method-shadowing-base-method.rst index aff3e1e6b6fb0..4906b501f9ff3 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/derived-method-shadowing-base-method.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/derived-method-shadowing-base-method.rst @@ -10,11 +10,12 @@ In order to be considered "shadowing", methods must have the same signature Only checks public, non-templated methods. The below example is bugprone because consumers of the ``Derived`` class will -expect the ``reset`` method to do the work of ``Base::reset()`` in addition to extra -work required to reset the ``Derived`` class. Common fixes include: +expect the ``reset`` method to do the work of ``Base::reset()`` in addition to +extra work required to reset the ``Derived`` class. Common fixes include: - Making the ``reset`` method polymorphic -- Re-naming ``Derived::reset`` if it's not meant to intersect with ``Base::reset`` +- Re-naming ``Derived::reset`` if it's not meant to intersect with + ``Base::reset`` - Using ``using Base::reset`` to change the access specifier This is also a violation of the Liskov Substitution Principle. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/dynamic-static-initializers.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/dynamic-static-initializers.rst index b4d5f75048a09..93d403cd112d4 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/dynamic-static-initializers.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/dynamic-static-initializers.rst @@ -8,12 +8,12 @@ in header files. This can pose problems in certain multithreaded contexts. For example, when disabling compiler generated synchronization instructions for -static variables initialized at runtime (e.g. by ``-fno-threadsafe-statics``), even if a particular project -takes the necessary precautions to prevent race conditions during -initialization by providing their own synchronization, header files included from other projects may -not. Therefore, such a check is helpful for ensuring that disabling -compiler generated synchronization for static variable initialization will not cause -problems. +static variables initialized at runtime (e.g. by ``-fno-threadsafe-statics``), +even if a particular project takes the necessary precautions to prevent race +conditions during initialization by providing their own synchronization, header +files included from other projects may not. Therefore, such a check is helpful +for ensuring that disabling compiler generated synchronization for static +variable initialization will not cause problems. Consider the following code: @@ -24,4 +24,6 @@ Consider the following code: return k; } -When synchronization of static initialization is disabled, if two threads both call `foo` for the first time, there is the possibility that `k` will be double initialized, creating a race condition. +When synchronization of static initialization is disabled, if two threads both +call `foo` for the first time, there is the possibility that `k` will be double +initialized, creating a race condition. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/easily-swappable-parameters.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/easily-swappable-parameters.rst index a96d7f6015bda..59ccab4851dcc 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/easily-swappable-parameters.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/easily-swappable-parameters.rst @@ -12,9 +12,9 @@ swapped (or badly ordered) arguments. void drawPoint(int X, int Y) { /* ... */ } FILE *open(const char *Dir, const char *Name, Flags Mode) { /* ... */ } -A potential call like ``drawPoint(-2, 5)`` or ``openPath("a.txt", "tmp", Read)`` -is perfectly legal from the language's perspective, but might not be what the -developer of the function intended. +A potential call like ``drawPoint(-2, 5)`` or +``openPath("a.txt", "tmp", Read)`` is perfectly legal from the language's +perspective, but might not be what the developer of the function intended. More elaborate and type-safe constructs, such as opaque typedefs or strong types should be used instead, to prevent a mistaken order of arguments. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst index fd1db594ddb24..87c7edc30f2d4 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst @@ -118,10 +118,10 @@ Here is an example: it->second.callFunction(); } -In conclusion, empty catch statements are a bad practice that can lead to hidden -bugs, security issues, poor code quality, and unreliable code. By handling -exceptions properly, developers can ensure that their code is robust, secure, -and maintainable. +In conclusion, empty catch statements are a bad practice that can lead to +hidden bugs, security issues, poor code quality, and unreliable code. By +handling exceptions properly, developers can ensure that their code is +robust, secure, and maintainable. Options ------- diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-copy-constructor-throws.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-copy-constructor-throws.rst index 8c3becf80a541..7170501328ade 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-copy-constructor-throws.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-copy-constructor-throws.rst @@ -28,4 +28,4 @@ References This check corresponds to the CERT C++ Coding Standard rule `ERR60-CPP. Exception objects must be nothrow copy constructible -`_. \ No newline at end of file +`_. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-escape.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-escape.rst index 7eaa333d5403a..7d724a4581715 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-escape.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/exception-escape.rst @@ -26,9 +26,9 @@ function also results in unexpected termination. Functions declared explicitly with ``noexcept(false)`` or ``throw(exception)`` will be excluded from the analysis, as even though it is not recommended for -functions like ``swap()``, ``main()``, move constructors, move assignment operators -and destructors, it is a clear indication of the developer's intention and -should be respected. +functions like ``swap()``, ``main()``, move constructors, move assignment +operators and destructors, it is a clear indication of the developer's +intention and should be respected. WARNING! This check may be expensive on large source files. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/fold-init-type.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/fold-init-type.rst index 8c6872d72f11a..fefad9f5e535b 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/fold-init-type.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/fold-init-type.rst @@ -6,13 +6,14 @@ bugprone-fold-init-type The check flags type mismatches in `folds `_ like ``std::accumulate`` that might result in loss of precision. -``std::accumulate`` folds an input range into an initial value using the type of -the latter, with ``operator+`` by default. This can cause loss of precision -through: +``std::accumulate`` folds an input range into an initial value using +the type of the latter, with ``operator+`` by default. This can cause +loss of precision through: - Truncation: The following code uses a floating point range and an int - initial value, so truncation will happen at every application of ``operator+`` - and the result will be `0`, which might not be what the user expected. + initial value, so truncation will happen at every application of + ``operator+`` and the result will be `0`, which might not be what the + user expected. .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/forward-declaration-namespace.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/forward-declaration-namespace.rst index 99ecb63e7b9c6..5e04f660330d9 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/forward-declaration-namespace.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/forward-declaration-namespace.rst @@ -17,4 +17,5 @@ the forward declaration is in a potentially wrong namespace. // warning : no definition found for 'A', but a definition with the same name // 'A' found in another namespace 'nb::' -This check can only generate warnings, but it can't suggest a fix at this point. +This check can only generate warnings, but it can't suggest a fix at this +point. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst index 6d70a50d2e9ca..cd079a35a38e2 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst @@ -6,8 +6,8 @@ bugprone-forwarding-reference-overload The check looks for perfect forwarding constructors that can hide copy or move constructors. If a non const lvalue reference is passed to the constructor, the forwarding reference parameter will be a better match than the const reference -parameter of the copy constructor, so the perfect forwarding constructor will be -called, which can be confusing. +parameter of the copy constructor, so the perfect forwarding constructor will +be called, which can be confusing. For detailed description of this issue see: Scott Meyers, Effective Modern C++, Item 26. @@ -47,12 +47,12 @@ Consider the following example: Person(const Person& rhs); }; -The check warns for constructors C1 and C2, because those can hide copy and move -constructors. We suppress warnings if the copy and the move constructors are both -disabled (deleted or private), because there is nothing the perfect forwarding -constructor could hide in this case. We also suppress warnings for constructors -like C3-C6 that are guarded with an ``enable_if`` or a concept, assuming the -programmer was aware of the possible hiding. +The check warns for constructors C1 and C2, because those can hide copy and +move constructors. We suppress warnings if the copy and the move constructors +are both disabled (deleted or private), because there is nothing the perfect +forwarding constructor could hide in this case. We also suppress warnings for +constructors like C3-C6 that are guarded with an ``enable_if`` or a concept, +assuming the programmer was aware of the possible hiding. Background ---------- diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst index 380033ff09089..f3f0331b15b5e 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst @@ -7,9 +7,9 @@ Detects when a variable is both incremented/decremented and referenced inside a complex condition and suggests moving them outside to avoid ambiguity in the variable's value. -When a variable is modified and also used in a complex condition, it can lead to -unexpected behavior. The side-effect of changing the variable's value within the -condition can make the code difficult to reason about. Additionally, the +When a variable is modified and also used in a complex condition, it can lead +to unexpected behavior. The side-effect of changing the variable's value within +the condition can make the code difficult to reason about. Additionally, the developer's intended timing for the modification of the variable may not be clear, leading to misunderstandings and errors. This can be particularly problematic when the condition involves logical operators like ``&&`` and @@ -44,8 +44,8 @@ throughout the code. // do something } -Another common issue occurs when multiple increments or decrements are performed -on the same variable inside a complex condition. For example: +Another common issue occurs when multiple increments or decrements are +performed on the same variable inside a complex condition. For example: .. code-block:: c++ @@ -55,13 +55,14 @@ on the same variable inside a complex condition. For example: // do something } -There is a potential issue with this code due to the order of evaluation in C++. -The ``||`` operator used in the condition statement guarantees that if the first -operand evaluates to ``true``, the second operand will not be evaluated. This -means that if ``i`` were initially ``4``, the first operand ``i < 5`` would -evaluate to ``true`` and the second operand ``i > 2`` would not be evaluated. -As a result, the decrement operation ``--i`` would not be executed and ``i`` -would hold value ``5``, which may not be the intended behavior for the developer. +There is a potential issue with this code due to the order of evaluation in +C++. The ``||`` operator used in the condition statement guarantees that if +the first operand evaluates to ``true``, the second operand will not be +evaluated. This means that if ``i`` were initially ``4``, the first operand +``i < 5`` would evaluate to ``true`` and the second operand ``i > 2`` would +not be evaluated. As a result, the decrement operation ``--i`` would not be +executed and ``i`` would hold value ``5``, which may not be the intended +behavior for the developer. To avoid this potential issue, the both increment and decrement operation on ``i`` should be moved outside the condition statement. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst index 89502c1882a92..bbbc8773868a4 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst @@ -11,15 +11,15 @@ However, it is possible to detect some obvious infinite loops, for example, if the loop condition is not changed. This check detects such loops. A loop is considered infinite if it does not have any loop exit statement (``break``, ``continue``, ``goto``, ``return``, ``throw`` or a call to a function called as -``[[noreturn]]``) and all of the following conditions hold for every variable in -the condition: +``[[noreturn]]``) and all of the following conditions hold for every variable +in the condition: - It is a local variable. - It has no reference or pointer aliases. - It is not a structure or class member. -Furthermore, the condition must not contain a function call to consider the loop -infinite since functions may return different values for different calls. +Furthermore, the condition must not contain a function call to consider the +loop infinite since functions may return different values for different calls. For example, the following loop is considered infinite `i` is not changed in the body: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst index 45cb878383a7d..fcbfce751828d 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst @@ -19,8 +19,8 @@ The check emits a warning only if an ``enum`` variable is default-initialized value of 0. The type can be a scoped or non-scoped ``enum``. Unions are not handled by the check (if it contains a member of enumeration type). -Note that the ``enum`` ``std::errc`` is always ignored because it is expected to -be default initialized, despite not defining an enumerator with the value 0. +Note that the ``enum`` ``std::errc`` is always ignored because it is expected +to be default initialized, despite not defining an enumerator with the value 0. .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst index 38df4803b45f3..c9a2a648578ce 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst @@ -4,14 +4,14 @@ bugprone-misplaced-operator-in-strlen-in-alloc ============================================== Finds cases where ``1`` is added to the string in the argument to ``strlen()``, -``strnlen()``, ``strnlen_s()``, ``wcslen()``, ``wcsnlen()``, and ``wcsnlen_s()`` -instead of the result and the value is used as an argument to a memory -allocation function (``malloc()``, ``calloc()``, ``realloc()``, ``alloca()``) or -the ``new[]`` operator in `C++`. The check detects error cases even if one of -these functions (except the ``new[]`` operator) is called by a constant function -pointer. Cases where ``1`` is added both to the parameter and the result of the -``strlen()``-like function are ignored, as are cases where the whole addition is -surrounded by extra parentheses. +``strnlen()``, ``strnlen_s()``, ``wcslen()``, ``wcsnlen()``, and +``wcsnlen_s()`` instead of the result and the value is used as an argument to a +memory allocation function (``malloc()``, ``calloc()``, ``realloc()``, +``alloca()``) or the ``new[]`` operator in `C++`. The check detects error cases +even if one of these functions (except the ``new[]`` operator) is called by a +constant function pointer. Cases where ``1`` is added both to the parameter and +the result of the ``strlen()``-like function are ignored, as are cases where +the whole addition is surrounded by extra parentheses. `C` example code: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst index b9b8984ef6584..154013da516d3 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst @@ -10,11 +10,11 @@ and throws exception. C++ does often not specify the exact order of evaluation of the operands of an operator or arguments of a function. Therefore if a first allocation succeeds and a second fails, in an exception handler it is not possible to tell which -allocation has failed and free the memory. Even if the order is fixed the result -of a first ``new`` may be stored in a temporary location that is not reachable -at the time when a second allocation fails. It is best to avoid any expression -that contains more than one ``operator new`` call, if exception handling is -used to check for allocation errors. +allocation has failed and free the memory. Even if the order is fixed the +result of a first ``new`` may be stored in a temporary location that is not +reachable at the time when a second allocation fails. It is best to avoid any +expression that contains more than one ``operator new`` call, if exception +handling is used to check for allocation errors. Different rules apply for are the short-circuit operators ``||`` and ``&&`` and the ``,`` operator, where evaluation of one side must be completed before the @@ -31,9 +31,9 @@ For any warning to be emitted the ``new`` calls should be in a code block where exception handling is used with catch for ``std::bad_alloc`` or ``std::exception``. At ``||``, ``&&``, ``,``, ``?`` (condition and one branch) operators no warning is emitted. No warning is emitted if both of the memory -allocations are not assigned to a variable or not passed directly to a function. -The reason is that in this case the memory may be intentionally not freed or the -allocated objects can be self-destructing objects. +allocations are not assigned to a variable or not passed directly to a +function. The reason is that in this case the memory may be intentionally not +freed or the allocated objects can be self-destructing objects. Examples: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst index 1a1217ed5a21c..4327bc09babab 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst @@ -3,7 +3,8 @@ bugprone-narrowing-conversions ============================== -`cppcoreguidelines-narrowing-conversions` redirects here as an alias for this check. +`cppcoreguidelines-narrowing-conversions` redirects here as an alias for +this check. Checks for silent narrowing conversions, e.g: ``int i = 0; i += 0.1;``. While the issue is obvious in this former example, it might not be so in the @@ -19,8 +20,8 @@ We flag narrowing conversions from: if WarnOnFloatingPointNarrowingConversion Option is set. This check will flag: - - All narrowing conversions that are not marked by an explicit cast (c-style or - ``static_cast``). For example: ``int i = 0; i += 0.1;``, + - All narrowing conversions that are not marked by an explicit cast (c-style + or ``static_cast``). For example: ``int i = 0; i += 0.1;``, ``void f(int); f(0.1);``, - All applications of binary operators with a narrowing conversions. For example: ``int i; i+= 0.1;``. @@ -110,17 +111,17 @@ FAQ - What does "narrowing conversion from 'int' to 'float'" mean? An IEEE754 Floating Point number can represent all integer values in the range -[-2^PrecisionBits, 2^PrecisionBits] where PrecisionBits is the number of bits in -the mantissa. +[-2^PrecisionBits, 2^PrecisionBits] where PrecisionBits is the number of bits +in the mantissa. -For ``float`` this would be [-2^23, 2^23], where ``int`` can represent values in -the range [-2^31, 2^31-1]. +For ``float`` this would be [-2^23, 2^23], where ``int`` can represent values +in the range [-2^31, 2^31-1]. - What does "implementation-defined" mean? -You may have encountered messages like "narrowing conversion from 'unsigned int' -to signed type 'int' is implementation-defined". -The C/C++ standard does not mandate two's complement for signed integers, and so -the compiler is free to define what the semantics are for converting an unsigned -integer to signed integer. Clang's implementation uses the two's complement -format. +You may have encountered messages like "narrowing conversion from 'unsigned +int' to signed type 'int' is implementation-defined". +The C/C++ standard does not mandate two's complement for signed integers, and +so the compiler is free to define what the semantics are for converting an +unsigned integer to signed integer. Clang's implementation uses the two's +complement format. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/no-escape.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/no-escape.rst index 770a71cc04255..850b01c4d76f6 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/no-escape.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/no-escape.rst @@ -5,8 +5,8 @@ bugprone-no-escape Finds pointers with the ``noescape`` attribute that are captured by an asynchronously-executed block. The block arguments in ``dispatch_async()`` and -``dispatch_after()`` are guaranteed to escape, so it is an error if a pointer with the -``noescape`` attribute is captured by one of these blocks. +``dispatch_after()`` are guaranteed to escape, so it is an error if a pointer +with the ``noescape`` attribute is captured by one of these blocks. The following is an example of an invalid use of the ``noescape`` attribute. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst index 168ed71674773..0ae950d75316e 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst @@ -3,24 +3,24 @@ bugprone-non-zero-enum-to-bool-conversion ========================================= -Detect implicit and explicit casts of ``enum`` type into ``bool`` where ``enum`` -type doesn't have a zero-value enumerator. If the ``enum`` is used only to hold -values equal to its enumerators, then conversion to ``bool`` will always result -in ``true`` value. This can lead to unnecessary code that reduces readability -and maintainability and can result in bugs. +Detect implicit and explicit casts of ``enum`` type into ``bool`` where +``enum`` type doesn't have a zero-value enumerator. If the ``enum`` is used +only to hold values equal to its enumerators, then conversion to ``bool`` will +always result in ``true`` value. This can lead to unnecessary code that reduces +readability and maintainability and can result in bugs. May produce false positives if the ``enum`` is used to store other values (used as a bit-mask or zero-initialized on purpose). To deal with them, -``// NOLINT`` or casting first to the underlying type before casting to ``bool`` -can be used. +``// NOLINT`` or casting first to the underlying type before casting to +``bool`` can be used. It is important to note that this check will not generate warnings if the definition of the enumeration type is not available. Additionally, C++11 enumeration classes are supported by this check. -Overall, this check serves to improve code quality and readability by identifying -and flagging instances where implicit or explicit casts from enumeration types to -boolean could cause potential issues. +Overall, this check serves to improve code quality and readability by +identifying and flagging instances where implicit or explicit casts from +enumeration types to boolean could cause potential issues. Example ------- diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst index ed7d65c3a89be..db86e94063ec0 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst @@ -3,10 +3,11 @@ bugprone-not-null-terminated-result =================================== -Finds function calls where it is possible to cause a not null-terminated result. -Usually the proper length of a string is ``strlen(src) + 1`` or equal length of -this expression, because the null terminator needs an extra space. Without the -null terminator it can result in undefined behavior when the string is read. +Finds function calls where it is possible to cause a not null-terminated +result. Usually the proper length of a string is ``strlen(src) + 1`` or equal +length of this expression, because the null terminator needs an extra space. +Without the null terminator it can result in undefined behavior when the +string is read. The following and their respective ``wchar_t`` based functions are checked: @@ -25,8 +26,8 @@ of the allocated memory is not enough to hold the null terminator. return result; } -In addition to issuing warnings, fix-it rewrites all the necessary code. It also -tries to adjust the capacity of the destination array: +In addition to issuing warnings, fix-it rewrites all the necessary code. +It also tries to adjust the capacity of the destination array: .. code-block:: c @@ -62,8 +63,8 @@ Rewrite based on the destination array the safe version (ending with ``cpy_s``). - If the new function is could be safe version and C++ files are analyzed and - the destination array is plain ``char``/``wchar_t`` without ``un/signed`` then - the length of the destination array can be omitted. + the destination array is plain ``char``/``wchar_t`` without ``un/signed`` + then the length of the destination array can be omitted. - If the new function is could be safe version and the destination array is ``un/signed`` it needs to be casted to plain ``char *``/``wchar_t *``. @@ -76,8 +77,9 @@ Rewrite based on the length of the source string ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - If the given length is ``strlen(source)`` or equal length of this expression - then the new function should be the older copy function (ending with ``cpy``), - as it is more efficient than the safe version (ending with ``cpy_s``). + then the new function should be the older copy function (ending with + ``cpy``), as it is more efficient than the safe version (ending with + ``cpy_s``). - Otherwise we assume that the programmer wanted to copy 'N' characters, so the new function is ``ncpy``-like which copies 'N' characters. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/posix-return.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/posix-return.rst index a5c4ccb0c4d7c..1a4a3ed3b9a37 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/posix-return.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/posix-return.rst @@ -13,7 +13,8 @@ Example buggy usage looks like: if (posix_fadvise(...) < 0) { -This will never happen as the return value is always non-negative. A simple fix could be: +This will never happen as the return value is always non-negative. +A simple fix could be: .. code-block:: c diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/random-generator-seed.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/random-generator-seed.rst index 25712447f7897..25680994a58d2 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/random-generator-seed.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/random-generator-seed.rst @@ -4,10 +4,10 @@ bugprone-random-generator-seed ============================== Flags all pseudo-random number engines, engine adaptor -instantiations and ``srand()`` when initialized or seeded with default argument, -constant expression or any user-configurable type. Pseudo-random number -engines seeded with a predictable value may cause vulnerabilities e.g. in -security protocols. +instantiations and ``srand()`` when initialized or seeded with default +argument, constant expression or any user-configurable type. Pseudo-random +number engines seeded with a predictable value may cause vulnerabilities +e.g. in security protocols. Examples: @@ -41,4 +41,4 @@ This check corresponds to the CERT C++ Coding Standard rules `MSC51-CPP. Ensure your random number generator is properly seeded `_ and `MSC32-C. Properly seed pseudorandom number generators -`_. \ No newline at end of file +`_. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/redundant-branch-condition.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/redundant-branch-condition.rst index c2efff8dec1cd..7a321bd9c0f06 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/redundant-branch-condition.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/redundant-branch-condition.rst @@ -16,9 +16,9 @@ Simple example: scream(); } -Here `onFire` is checked both in the outer ``if`` and the inner ``if`` statement -without a possible change between the two checks. The check warns for this code -and suggests removal of the second checking of variable `onFire`. +Here `onFire` is checked both in the outer ``if`` and the inner ``if`` +statement without a possible change between the two checks. The check warns for +this code and suggests removal of the second checking of variable `onFire`. The checker also detects redundant condition checks if the condition variable is an operand of a logical "and" (``&&``) or a logical "or" (``||``) operator: @@ -44,8 +44,8 @@ condition variable and keep the other side of the ``&&``. In the second case (logical "or") the whole ``if`` is removed similarly to the simple case on the top. -The condition of the outer ``if`` statement may also be a logical "and" (``&&``) -expression: +The condition of the outer ``if`` statement may also be a logical "and" +(``&&``) expression: .. code-block:: c @@ -62,8 +62,8 @@ The error is also detected if both the outer statement is a logical "and" The inner ``if`` statement does not have to be a direct descendant of the outer one. -No error is detected if the condition variable may have been changed between the -two checks: +No error is detected if the condition variable may have been changed between +the two checks: .. code-block:: c diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/return-const-ref-from-parameter.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/return-const-ref-from-parameter.rst index 00759a2ca003b..663e2149c7ac9 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/return-const-ref-from-parameter.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/return-const-ref-from-parameter.rst @@ -3,14 +3,14 @@ bugprone-return-const-ref-from-parameter ======================================== -Detects return statements that return a constant reference parameter as constant -reference. This may cause use-after-free errors if the caller uses xvalues as -arguments. - -In C++, constant reference parameters can accept xvalues which will be destructed -after the call. When the function returns such a parameter also as constant reference, -then the returned reference can be used after the object it refers to has been -destroyed. +Detects return statements that return a constant reference parameter as +constant reference. This may cause use-after-free errors if the caller +uses xvalues as arguments. + +In C++, constant reference parameters can accept xvalues which will be +destructed after the call. When the function returns such a parameter also +as constant reference, then the returned reference can be used after the +object it refers to has been destroyed. Example ------- diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst index 848fb667e1823..aef27942b9e92 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst @@ -20,10 +20,10 @@ Checked signal handler rules for up to and including C++14: The check is disabled on C++17 and later. -Asynchronous-safety is determined by comparing the function's name against a set -of known functions. In addition, the function must come from a system header -include and in a global namespace. The (possible) arguments passed to the -function are not checked. Any function that cannot be determined to be +Asynchronous-safety is determined by comparing the function's name against a +set of known functions. In addition, the function must come from a system +header include and in a global namespace. The (possible) arguments passed to +the function are not checked. Any function that cannot be determined to be asynchronous-safe is assumed to be non-asynchronous-safe by the check, including user functions for which only the declaration is visible. Calls to user-defined functions with visible definitions are checked diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/signed-char-misuse.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/signed-char-misuse.rst index 3e06e11dffcc7..4b98c36ee84c9 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/signed-char-misuse.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/signed-char-misuse.rst @@ -17,30 +17,34 @@ human programmer probably expects that the converted value matches with the character code (a value from [0..255]), however, the actual value is in [-128..127] interval. To avoid this kind of misinterpretation, the desired way of converting from a ``signed char`` to an integer value is converting to -``unsigned char`` first, which stores all the characters in the positive [0..255] -interval which matches the known character codes. +``unsigned char`` first, which stores all the characters in the positive +[0..255] interval which matches the known character codes. In case of implicit conversion, the programmer might not actually be aware that a conversion happened and char value is used as an integer. There are -some use cases when this unawareness might lead to a functionally imperfect code. -For example, checking the equality of a ``signed char`` and an ``unsigned char`` -variable is something we should avoid in C++ code. During this comparison, -the two variables are converted to integers which have different value ranges. -For ``signed char``, the non-ASCII characters are stored as a value in [-128..-1] -interval, while the same characters are stored in the [128..255] interval for -an ``unsigned char``. - -It depends on the actual platform whether plain ``char`` is handled as ``signed char`` -by default and so it is caught by this check or not. To change the default behavior -you can use ``-funsigned-char`` and ``-fsigned-char`` compilation options. +some use cases when this unawareness might lead to a functionally imperfect +code. For example, checking the equality of a ``signed char`` and an +``unsigned char`` variable is something we should avoid in C++ code. During +this comparison, the two variables are converted to integers which have +different value ranges. For ``signed char``, the non-ASCII characters are +stored as a value in [-128..-1] interval, while the same characters are +stored in the [128..255] interval for an ``unsigned char``. + +It depends on the actual platform whether plain ``char`` is handled as +``signed char`` by default and so it is caught by this check or not. +To change the default behavior you can use ``-funsigned-char`` and +``-fsigned-char`` compilation options. Currently, this check warns in the following cases: + - ``signed char`` is assigned to an integer variable -- ``signed char`` and ``unsigned char`` are compared with equality/inequality operator +- ``signed char`` and ``unsigned char`` are compared with + equality/inequality operator - ``signed char`` is converted to an integer in the array subscript See also: -`STR34-C. Cast characters to unsigned char before converting to larger integer sizes +`STR34-C. Cast characters to unsigned char before converting to larger +integer sizes `_ A good example from the CERT description when a ``char`` variable is used to diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-container.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-container.rst index fb2f0b2a6801c..5d70d45a91357 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-container.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-container.rst @@ -3,12 +3,12 @@ bugprone-sizeof-container ========================= -The check finds usages of ``sizeof`` on expressions of STL container types. Most -likely the user wanted to use ``.size()`` instead. +The check finds usages of ``sizeof`` on expressions of STL container types. +Most likely the user wanted to use ``.size()`` instead. -All class/struct types declared in namespace ``std::`` having a const ``size()`` -method are considered containers, with the exception of ``std::bitset`` and -``std::array``. +All class/struct types declared in namespace ``std::`` having a const +``size()`` method are considered containers, with the exception of +``std::bitset`` and ``std::array``. Examples: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-expression.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-expression.rst index 09be75c9de03a..aa2e529628c0e 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-expression.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/sizeof-expression.rst @@ -73,9 +73,9 @@ Suspicious usage of 'sizeof(char*)' There is a subtle difference between declaring a string literal with ``char* A = ""`` and ``char A[] = ""``. The first case has the type ``char*`` -instead of the aggregate type ``char[]``. Using ``sizeof`` on an object declared -with ``char*`` type is returning the size of a pointer instead of the number of -characters (bytes) in the string literal. +instead of the aggregate type ``char[]``. Using ``sizeof`` on an object +declared with ``char*`` type is returning the size of a pointer instead of +the number of characters (bytes) in the string literal. .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/std-namespace-modification.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/std-namespace-modification.rst index c6e5608280264..56d2559be904e 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/std-namespace-modification.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/std-namespace-modification.rst @@ -10,13 +10,18 @@ The ``std`` (or ``posix``) namespace is allowed to be extended with (class or function) template specializations that depend on an user-defined type (a type that is not defined in the standard system headers). -The check detects the following (user provided) declarations in namespace ``std`` or ``posix``: +The check detects the following (user provided) declarations in namespace +``std`` or ``posix``: - Anything that is not a template specialization. -- Explicit specializations of any standard library function template or class template, if it does not have any user-defined type as template argument. -- Explicit specializations of any member function of a standard library class template. -- Explicit specializations of any member function template of a standard library class or class template. -- Explicit or partial specialization of any member class template of a standard library class or class template. +- Explicit specializations of any standard library function template or class + template, if it does not have any user-defined type as template argument. +- Explicit specializations of any member function of a standard library class + template. +- Explicit specializations of any member function template of a standard + library class or class template. +- Explicit or partial specialization of any member class template of a standard + library class or class template. Examples: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/string-literal-with-embedded-nul.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/string-literal-with-embedded-nul.rst index c1c4d3261dfaf..bc5f2ce2cc885 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/string-literal-with-embedded-nul.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/string-literal-with-embedded-nul.rst @@ -21,9 +21,9 @@ like this ``\0x42`` where the ``\0`` stands for the NUL character. Truncated literal ----------------- -String-like classes can manipulate strings with embedded NUL as they are keeping -track of the bytes and the length. This is not the case for a ``char*`` -(NUL-terminated) string. +String-like classes can manipulate strings with embedded NUL as they are +keeping track of the bytes and the length. This is not the case for a +``char*`` (NUL-terminated) string. A common mistake is to pass a string-literal with embedded NUL to a string constructor expecting a NUL-terminated string. The bytes after the first NUL diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst index 94f29ee11ee39..386e50ae5ff37 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst @@ -3,11 +3,11 @@ bugprone-suspicious-enum-usage ============================== -The checker detects various cases when an enum is probably misused (as a bitmask -). +The checker detects various cases when an enum is probably misused +(as a bitmask). -1. When "ADD" or "bitwise OR" is used between two enum which come from different - types and these types value ranges are not disjoint. +1. When "ADD" or "bitwise OR" is used between two enum which come + from different types and these types value ranges are not disjoint. The following cases will be investigated only using :option:`StrictMode`. We regard the enum as a (suspicious) @@ -17,15 +17,15 @@ bitmask if the three conditions below are true at the same time: short enumerations) * there is another non pow-of-2 number than the enum constant representing all choices (the result "bitwise OR" operation of all enum elements) -* enum type variable/enumconstant is used as an argument of a `+` or "bitwise OR - " operator +* enum type variable/enumconstant is used as an argument of a `+` or "bitwise + OR" operator So whenever the non pow-of-2 element is used as a bitmask element we diagnose a misuse and give a warning. 2. Investigating the right hand side of `+=` and `|=` operator. -3. Check only the enum value side of a `|` and `+` operator if one of them is not - enum val. +3. Check only the enum value side of a `|` and `+` operator if one of them is + not enum val. 4. Check both side of `|` or `+` operator where the enum values are from the same enum type. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-memory-comparison.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-memory-comparison.rst index f82863f7c2f18..317f8e1839597 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-memory-comparison.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-memory-comparison.rst @@ -24,10 +24,12 @@ and `_ This check is also related to and partially overlaps the CERT C++ Coding Standard rules -`OOP57-CPP. Prefer special member functions and overloaded operators to C Standard Library functions +`OOP57-CPP. Prefer special member functions and overloaded operators to +C Standard Library functions `_ and -`EXP62-CPP. Do not access the bits of an object representation that are not part of the object's value representation +`EXP62-CPP. Do not access the bits of an object representation that are not +part of the object's value representation `_ `cert-exp42-c` redirects here as an alias of this check. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst index 25a0d8885689b..9885d9c2ae9ff 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-realloc-usage.rst @@ -3,8 +3,8 @@ bugprone-suspicious-realloc-usage ================================= -This check finds usages of ``realloc`` where the return value is assigned to the -same expression as passed to the first argument: +This check finds usages of ``realloc`` where the return value is assigned to +the same expression as passed to the first argument: ``p = realloc(p, size);`` The problem with this construct is that if ``realloc`` fails it returns a null pointer but does not deallocate the original memory. If no other variable @@ -12,8 +12,9 @@ is pointing to it, the original memory block is not available any more for the program to use or free. In either case ``p = realloc(p, size);`` indicates bad coding style and can be replaced by ``q = realloc(p, size);``. -The pointer expression (used at ``realloc``) can be a variable or a field member -of a data structure, but can not contain function calls or unresolved types. +The pointer expression (used at ``realloc``) can be a variable or a field +member of a data structure, but can not contain function calls or unresolved +types. In obvious cases when the pointer used at realloc is assigned to another variable before the ``realloc`` call, no warning is emitted. This happens only diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst index 76c891f3def4a..65594fa766910 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst @@ -5,9 +5,9 @@ bugprone-suspicious-semicolon Finds most instances of stray semicolons that unexpectedly alter the meaning of the code. More specifically, it looks for ``if``, ``while``, ``for`` and -``for-range`` statements whose body is a single semicolon, and then analyzes the -context of the code (e.g. indentation) in an attempt to determine whether that -is intentional. +``for-range`` statements whose body is a single semicolon, and then analyzes +the context of the code (e.g. indentation) in an attempt to determine whether +that is intentional. .. code-block:: c++ @@ -26,8 +26,8 @@ of the first line, and `x` will be incremented regardless of the condition. processLine(line); As a result of this code, `processLine()` will only be called once, when the -``while`` loop with the empty body exits with `line == NULL`. The indentation of -the code indicates the intention of the programmer. +``while`` loop with the empty body exits with `line == NULL`. The indentation +of the code indicates the intention of the programmer. .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.rst index 85e17967728bd..973b70393faf0 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-string-compare.rst @@ -30,8 +30,8 @@ A common mistake is to compare the result to `1` or `-1`. if (strcmp(...) == -1) // Incorrect usage of the returned value. Additionally, the check warns if the results value is implicitly cast to a -*suspicious* non-integer type. It's happening when the returned value is used in -a wrong context. +*suspicious* non-integer type. It's happening when the returned value is +used in a wrong context. .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.rst index 674108f9d01ed..e798b67937170 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/swapped-arguments.rst @@ -34,8 +34,8 @@ dealing with floating-point arguments, implicit casts between different floating-point types are considered acceptable. To avoid confusion, swaps where both swapped arguments are of integral types or -both are of floating-point types do not trigger the warning. In such cases, it's -assumed that the developer intentionally used different integral or +both are of floating-point types do not trigger the warning. In such cases, +it's assumed that the developer intentionally used different integral or floating-point types and does not raise a warning. This approach prevents false -positives and provides flexibility in handling situations where varying integral -or floating-point types are intentionally utilized. +positives and provides flexibility in handling situations where varying +integral or floating-point types are intentionally utilized. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.rst index a3469dc451562..5ac5e3240d7a6 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/tagged-union-member-count.rst @@ -53,10 +53,10 @@ How enum constants are counted ------------------------------ The main complicating factor when counting the number of enum constants is that -some of them might be auxiliary values that purposefully don't have a corresponding union -data member and are used for something else. For example the last enum constant -sometimes explicitly "points to" the last declared valid enum constant or -tracks how many enum constants have been declared. +some of them might be auxiliary values that purposefully don't have a +corresponding union data member and are used for something else. For example +the last enum constant sometimes explicitly "points to" the last declared valid +enum constant or tracks how many enum constants have been declared. For an illustration: @@ -76,23 +76,24 @@ For an illustration: TagCount, // is 3 }; -The check counts the number of distinct values among the enum constants and not the enum -constants themselves. This way the enum constants that are essentially just aliases of other -enum constants are not included in the final count. +The check counts the number of distinct values among the enum constants and not +the enum constants themselves. This way the enum constants that are essentially +just aliases of other enum constants are not included in the final count. -Handling of counting enum constants (ones like :code:`TagCount` in the previous code example) -is done by decreasing the number of enum values by one if the name of the last enum constant -starts with a prefix or ends with a suffix specified in :option:`CountingEnumPrefixes`, -:option:`CountingEnumSuffixes` and it's value is one less than the total number of distinct -values in the enum. +Handling of counting enum constants (ones like :code:`TagCount` in the previous +code example) is done by decreasing the number of enum values by one if the name +of the last enum constant starts with a prefix or ends with a suffix specified in +:option:`CountingEnumPrefixes`, :option:`CountingEnumSuffixes` and it's value is +one less than the total number of distinct values in the enum. -When the final count is adjusted based on this heuristic then a diagnostic note is emitted -that shows which enum constant matched the criteria. +When the final count is adjusted based on this heuristic then a diagnostic note +is emitted that shows which enum constant matched the criteria. -The heuristic can be disabled entirely (:option:`EnableCountingEnumHeuristic`) or -configured to follow your naming convention (:option:`CountingEnumPrefixes`, :option:`CountingEnumSuffixes`). -The strings specified in :option:`CountingEnumPrefixes`, :option:`CountingEnumSuffixes` are matched -case insensitively. +The heuristic can be disabled entirely (:option:`EnableCountingEnumHeuristic`) +or configured to follow your naming convention (:option:`CountingEnumPrefixes`, +:option:`CountingEnumSuffixes`). +The strings specified in :option:`CountingEnumPrefixes`, +:option:`CountingEnumSuffixes` are matched case insensitively. Example counts: @@ -184,8 +185,8 @@ If :option:`EnableCountingEnumHeuristic` is `false` then these options do nothin The default value of :option:`CountingEnumSuffixes` is `count` and of :option:`CountingEnumPrefixes` is the empty string. -When :option:`EnableCountingEnumHeuristic` is `true` and :option:`CountingEnumSuffixes` -is `count;size`: +When :option:`EnableCountingEnumHeuristic` is `true` and +:option:`CountingEnumSuffixes` is `count;size`: .. code-block:: c++ @@ -223,7 +224,8 @@ is `count;size`: } Data; }; -When :option:`EnableCountingEnumHeuristic` is `true` and :option:`CountingEnumPrefixes` is `maxsize;last_` +When :option:`EnableCountingEnumHeuristic` is `true` and +:option:`CountingEnumPrefixes` is `maxsize;last_` .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/throw-keyword-missing.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/throw-keyword-missing.rst index 240a62ed6b33c..be80fc8a84832 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/throw-keyword-missing.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/throw-keyword-missing.rst @@ -3,9 +3,10 @@ bugprone-throw-keyword-missing ============================== -Warns about a potentially missing ``throw`` keyword. If a temporary object is created, but the -object's type derives from (or is the same as) a class that has 'EXCEPTION', 'Exception' or -'exception' in its name, we can assume that the programmer's intention was to throw that object. +Warns about a potentially missing ``throw`` keyword. If a temporary object +is created, but the object's type derives from (or is the same as) a class +that has 'EXCEPTION', 'Exception' or 'exception' in its name, we can assume +that the programmer's intention was to throw that object. Example: diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/throwing-static-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/throwing-static-initialization.rst index 5e320a109c39c..4f88719dd6f5c 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/throwing-static-initialization.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/throwing-static-initialization.rst @@ -11,4 +11,4 @@ References This check corresponds to the CERT C++ Coding Standard rule `ERR58-CPP. Handle all exceptions thrown before main() begins executing -`_. \ No newline at end of file +`_. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/too-small-loop-variable.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/too-small-loop-variable.rst index 077abf0af6880..efba0ccf97493 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/too-small-loop-variable.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/too-small-loop-variable.rst @@ -14,10 +14,11 @@ iteration range. for (short i = 0; i < size; ++i) {} } -This ``for`` loop is an infinite loop because the ``short`` type can't represent -all values in the ``[0..size]`` interval. +This ``for`` loop is an infinite loop because the ``short`` type can't +represent all values in the ``[0..size]`` interval. -In a real use case size means a container's size which depends on the user input. +In a real use case size means a container's size which depends on the +user input. .. code-block:: c++ @@ -29,8 +30,9 @@ This algorithm works for a small amount of objects, but will lead to freeze for a larger user input. It's recommended to enable the compiler warning -`-Wtautological-constant-out-of-range-compare` as well, since check does not -inspect compile-time constant loop boundaries to avoid overlaps with the warning. +`-Wtautological-constant-out-of-range-compare` as well, since check does +not inspect compile-time constant loop boundaries to avoid overlaps with +the warning. Options ------- diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst index ebed79e339d4b..3423eaaf63eb2 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst @@ -15,9 +15,10 @@ types collectively as ``optional``. An access to the value of an ``optional`` occurs when one of its ``value``, ``operator*``, or ``operator->`` member functions is invoked. To align with -common misconceptions, the check considers these member functions as equivalent, -even though there are subtle differences related to exceptions versus undefined -behavior. See *Additional notes*, below, for more information on this topic. +common misconceptions, the check considers these member functions as +equivalent, even though there are subtle differences related to exceptions +versus undefined behavior. See *Additional notes*, below, for more information +on this topic. An access to the value of an ``optional`` is considered safe if and only if code in the local scope (for example, a function body) ensures that the @@ -208,8 +209,8 @@ local variable and use that variable to access the value. For example: Do not rely on uncommon-API invariants ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When uncommon APIs guarantee that an optional has contents, do not rely on it -- -instead, check explicitly that the optional object has a value. For example: +When uncommon APIs guarantee that an optional has contents, do not rely on it +-- instead, check explicitly that the optional object has a value. For example: .. code-block:: c++ @@ -293,8 +294,8 @@ or terminating the program), why treat it the same as ``operator*()`` which causes undefined behavior (UB)? That is, why is it considered unsafe to access an optional with ``value()``, if it's not provably populated with a value? For that matter, why is ``CHECK()`` followed by ``operator*()`` any better than -``value()``, given that they are semantically equivalent (on configurations that -disable exceptions)? +``value()``, given that they are semantically equivalent (on configurations +that disable exceptions)? The answer is that we assume most users do not realize the difference between ``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-string-to-number-conversion.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-string-to-number-conversion.rst index c3ea196511367..e38b29817f30a 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-string-to-number-conversion.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-string-to-number-conversion.rst @@ -5,8 +5,8 @@ bugprone-unchecked-string-to-number-conversion This check flags calls to string-to-number conversion functions that do not verify the validity of the conversion, such as ``atoi()`` or ``scanf()``. It -does not flag calls to ``strtol()``, or other, related conversion functions that -do perform better error checking. +does not flag calls to ``strtol()``, or other, related conversion functions +that do perform better error checking. .. code-block:: c diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-self-assignment.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-self-assignment.rst index 3a6245d2fe35b..07c4b33048add 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-self-assignment.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-self-assignment.rst @@ -10,9 +10,10 @@ Finds user-defined copy assignment operators which do not protect the code against self-assignment either by checking self-assignment explicitly or using the copy-and-swap or the copy-and-move method. -By default, this check searches only those classes which have any pointer or C array field -to avoid false positives. In case of a pointer or a C array, it's likely that self-copy -assignment breaks the object if the copy assignment operator was not written with care. +By default, this check searches only those classes which have any pointer or C +array field to avoid false positives. In case of a pointer or a C array, it's +likely that self-copy assignment breaks the object if the copy assignment +operator was not written with care. See also: `OOP54-CPP. Gracefully handle self-copy assignment @@ -90,9 +91,9 @@ The second one is the copy-and-swap method when we create a temporary copy } }; -There is a third pattern which is less common. Let's call it the copy-and-move method -when we create a temporary copy (using the copy constructor) and then move this -temporary object into ``this`` (needs a move assignment operator): +There is a third pattern which is less common. Let's call it the copy-and-move +method when we create a temporary copy (using the copy constructor) and then move +this temporary object into ``this`` (needs a move assignment operator): .. code-block:: c++ diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unintended-char-ostream-output.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unintended-char-ostream-output.rst index 29254c4321f68..da510c472e039 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unintended-char-ostream-output.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unintended-char-ostream-output.rst @@ -3,14 +3,14 @@ bugprone-unintended-char-ostream-output ======================================= -Finds unintended character output from ``unsigned char`` and ``signed char`` to an -``ostream``. +Finds unintended character output from ``unsigned char`` and ``signed char`` to +an ``ostream``. -Normally, when ``unsigned char (uint8_t)`` or ``signed char (int8_t)`` is used, it -is more likely a number than a character. However, when it is passed directly to -``std::ostream``'s ``operator<<``, the result is the character output instead -of the numeric value. This often contradicts the developer's intent to print -integer values. +Normally, when ``unsigned char (uint8_t)`` or ``signed char (int8_t)`` is used, +it is more likely a number than a character. However, when it is passed +directly to ``std::ostream``'s ``operator<<``, the result is the character +output instead of the numeric value. This often contradicts the developer's +intent to print integer values. .. code-block:: c++ @@ -26,8 +26,9 @@ intent, by default, it will cast to ``unsigned int`` for ``unsigned char`` and std::cout << static_cast(v); // when v is unsigned char std::cout << static_cast(v); // when v is signed char -To avoid lengthy cast statements, add prefix ``+`` to the variable can also -suppress warnings because unary expression will promote the value to an ``int``. +To avoid lengthy cast statements, add prefix ``+`` to the variable can +also suppress warnings because unary expression will promote the value +to an ``int``. .. code-block:: c++ @@ -44,11 +45,11 @@ Options .. option:: AllowedTypes - A semicolon-separated list of type names that will be treated like the ``char`` - type: the check will not report variables declared with with these types or - explicit cast expressions to these types. Note that this distinguishes type - aliases from the original type, so specifying e.g. ``unsigned char`` here - will not suppress reports about ``uint8_t`` even if it is defined as a + A semicolon-separated list of type names that will be treated like the ``char`` + type: the check will not report variables declared with with these types or + explicit cast expressions to these types. Note that this distinguishes type + aliases from the original type, so specifying e.g. ``unsigned char`` here + will not suppress reports about ``uint8_t`` even if it is defined as a ``typedef`` alias for ``unsigned char``. Default is `unsigned char;signed char`. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst index 6937c5177b6c2..f1fec13739271 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst @@ -19,7 +19,8 @@ The check implements the following rules from the CERT C Coding Standard: Unsafe functions ---------------- -The following functions are reported if :option:`ReportDefaultFunctions` is enabled. +The following functions are reported if :option:`ReportDefaultFunctions` +is enabled. If *Annex K.* is available, a replacement from *Annex K.* is suggested for the following functions: @@ -42,7 +43,8 @@ following functions from the previous list: - ``asctime``, ``asctime_r``, suggested replacement: ``strftime`` - ``gets``, suggested replacement: ``fgets`` -The following functions are always checked, regardless of *Annex K* availability: +The following functions are always checked, regardless of *Annex K* +availability: - ``rewind``, suggested replacement: ``fseek`` - ``setbuf``, suggested replacement: ``setvbuf`` @@ -80,8 +82,8 @@ including any system headers. Custom functions ---------------- -The option :option:`CustomFunctions` allows the user to define custom functions to be -checked. The format is the following, without newlines: +The option :option:`CustomFunctions` allows the user to define custom functions +to be checked. The format is the following, without newlines: .. code:: @@ -94,8 +96,9 @@ checked. The format is the following, without newlines: The functions are matched using POSIX extended regular expressions. *(Note: The regular expressions do not support negative* ``(?!)`` *matches.)* -The `reason` is optional and is used to provide additional information about the -reasoning behind the replacement. The default reason is `is marked as unsafe`. +The `reason` is optional and is used to provide additional information +about the reasoning behind the replacement. The default reason is +`is marked as unsafe`. If `replacement` is empty, the text `it should not be used` will be shown instead of the suggestion for a replacement. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-return-value.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-return-value.rst index 10ae0fe3243a0..725403a6eb818 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-return-value.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unused-return-value.rst @@ -3,7 +3,8 @@ bugprone-unused-return-value ============================ -Warns on unused function return values. The checked functions can be configured. +Warns on unused function return values. The checked functions can be +configured. Operator overloading with assignment semantics are ignored. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/use-after-move.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/use-after-move.rst index 965fc2d3c29e2..07edd07b1c4c9 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/use-after-move.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/use-after-move.rst @@ -83,9 +83,9 @@ move: std::cout << str; } -If you want to avoid the overhead of actually reinitializing the object, you can -create a dummy function that causes the check to assume the object was -reinitialized: +If you want to avoid the overhead of actually reinitializing the object, +you can create a dummy function that causes the check to assume the object +was reinitialized: .. code-block:: c++ @@ -104,9 +104,9 @@ You can use this as follows: std::cout << str; } -The check will not output a warning in this case because passing the object to a -function as a non-const pointer or reference counts as a reinitialization (see section -`Reinitialization`_ below). +The check will not output a warning in this case because passing the object +to a function as a non-const pointer or reference counts as a reinitialization +(see section `Reinitialization`_ below). Unsequenced moves, uses, and reinitializations ---------------------------------------------- @@ -143,10 +143,10 @@ reference parameter. This means that the check will flag a use-after-move even on a type that does not define a move constructor or move assignment operator. This is intentional. -Developers may use ``std::move`` on such a type in the expectation that the type -will add move semantics in the future. If such a ``std::move`` has the potential -to cause a use-after-move, we want to warn about it even if the type does not -implement move semantics yet. +Developers may use ``std::move`` on such a type in the expectation that the +type will add move semantics in the future. If such a ``std::move`` has the +potential to cause a use-after-move, we want to warn about it even if the type +does not implement move semantics yet. Furthermore, if the result of ``std::move`` *is* passed to an rvalue reference parameter, this will always be considered to cause a move, even if the function @@ -169,9 +169,9 @@ that a move always takes place: The check will assume that the last line causes a move, even though, in this particular case, it does not. Again, this is intentional. -There is one special case: A call to ``std::move`` inside a ``try_emplace`` call -is conservatively assumed not to move. This is to avoid spurious warnings, as -the check has no way to reason about the ``bool`` returned by ``try_emplace``. +There is one special case: A call to ``std::move`` inside a ``try_emplace`` +call is conservatively assumed not to move. This is to avoid spurious warnings, +as the check has no way to reason about the ``bool`` returned by ``try_emplace``. When analyzing the order in which moves, uses and reinitializations happen (see section `Unsequenced moves, uses, and reinitializations`_), the move is assumed @@ -198,8 +198,8 @@ is considered to be a use. An exception to this are objects of type ``std::unique_ptr``, ``std::shared_ptr``, ``std::weak_ptr``, ``std::optional``, and ``std::any``. An exception to this are objects of type ``std::unique_ptr``, -``std::shared_ptr``, ``std::weak_ptr``, ``std::optional``, and ``std::any``, which -can be reinitialized via ``reset``. For smart pointers specifically, the +``std::shared_ptr``, ``std::weak_ptr``, ``std::optional``, and ``std::any``, +which can be reinitialized via ``reset``. For smart pointers specifically, the moved-from objects have a well-defined state of being ``nullptr``s, and only ``operator*``, ``operator->`` and ``operator[]`` are considered bad accesses as they would be dereferencing a ``nullptr``. @@ -217,10 +217,10 @@ The check considers a variable to be reinitialized in the following cases: lvalue reference. (It is assumed that the variable may be an out-parameter for the function.) - - ``clear()`` or ``assign()`` is called on the variable and the variable is of - one of the standard container types ``basic_string``, ``vector``, ``deque``, - ``forward_list``, ``list``, ``set``, ``map``, ``multiset``, ``multimap``, - ``unordered_set``, ``unordered_map``, ``unordered_multiset``, + - ``clear()`` or ``assign()`` is called on the variable and the variable is + of one of the standard container types ``basic_string``, ``vector``, + ``deque``, ``forward_list``, ``list``, ``set``, ``map``, ``multiset``, + ``multimap``, ``unordered_set``, ``unordered_map``, ``unordered_multiset``, ``unordered_multimap``. - ``reset()`` is called on the variable and the variable is of type diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/virtual-near-miss.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/virtual-near-miss.rst index b3f02b839c4a4..d42268455b0c2 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/virtual-near-miss.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/virtual-near-miss.rst @@ -3,8 +3,9 @@ bugprone-virtual-near-miss ========================== -Warn if a function is a near miss (i.e. the name is very similar and the function -signature is the same) to a virtual function from a base class. +Warn if a function is a near miss (i.e. the name is very similar and +the function signature is the same) to a virtual function from a base +class. Example: From b7f78fa8043e8a06708d96c5724a7d3cd8fbd305 Mon Sep 17 00:00:00 2001 From: mtx Date: Thu, 13 Nov 2025 12:01:56 +0800 Subject: [PATCH 2/3] Fix formatting --- .../docs/clang-tidy/checks/android/cloexec-pipe.rst | 2 +- .../docs/clang-tidy/checks/android/cloexec-pipe2.rst | 4 ++-- .../android/comparison-in-temp-failure-retry.rst | 2 +- .../checks/bugprone/assignment-in-if-condition.rst | 2 +- .../checks/bugprone/suspicious-enum-usage.rst | 10 +++++----- 5 files changed, 10 insertions(+), 10 deletions(-) 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 45aba4209a1b7..c19e07f6c5dfe 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 @@ -4,7 +4,7 @@ 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 +``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. 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 7d438dac0f117..dc9c6fc411177 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,8 @@ 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 +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 cf5f43ded38d6..42e8dd97452ef 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,7 +22,7 @@ Example buggy usage looks like: // Do something with cs. } -Because TEMP_FAILURE_RETRY will check for whether the result +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 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 6e4b9c786f762..980e8146d0d64 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 @@ -9,7 +9,7 @@ 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 +including assignments that call an overloaded ``operator=()``. The identified assignments violate `BARR group "Rule 8.2.c" `_. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst index 386e50ae5ff37..94e3db9770cbc 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-enum-usage.rst @@ -23,11 +23,11 @@ bitmask if the three conditions below are true at the same time: So whenever the non pow-of-2 element is used as a bitmask element we diagnose a misuse and give a warning. -2. Investigating the right hand side of `+=` and `|=` operator. -3. Check only the enum value side of a `|` and `+` operator if one of them is - not enum val. -4. Check both side of `|` or `+` operator where the enum values are from the - same enum type. +2. Investigating the right hand side of ``+=`` and ``|=`` operator. +3. Check only the enum value side of a ``|`` and ``+`` operator if one of + them is not enum val. +4. Check both side of ``|`` or ``+`` operator where the enum values are from + the same enum type. Examples: From c59d1d3de028c73c310e36f7626680e494f8dac6 Mon Sep 17 00:00:00 2001 From: mtx Date: Thu, 13 Nov 2025 12:05:34 +0800 Subject: [PATCH 3/3] ~ --- .../docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst index 65594fa766910..56e23d77024cb 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-semicolon.rst @@ -26,7 +26,7 @@ of the first line, and `x` will be incremented regardless of the condition. processLine(line); As a result of this code, `processLine()` will only be called once, when the -``while`` loop with the empty body exits with `line == NULL`. The indentation +``while`` loop with the empty body exits with ``line == NULL``. The indentation of the code indicates the intention of the programmer.