[NFC] Trim trailing whitespace in *.rst

clang-tools-extra/docs/clang-tidy/checks/abseil-redundant-strcat-calls.rst

@@ -3,7 +3,7 @@
 abseil-redundant-strcat-calls
 =============================
 
-Suggests removal of unnecessary calls to ``absl::StrCat`` when the result is 
+Suggests removal of unnecessary calls to ``absl::StrCat`` when the result is
 being passed to another call to ``absl::StrCat`` or ``absl::StrAppend``.
 
 The extra calls cause unnecessary temporary strings to be constructed. Removing
@@ -21,6 +21,6 @@ Examples:
 
   absl::StrAppend(&s, absl::StrCat("E", "F", "G"));
   //before
-  
+
   absl::StrAppend(&s, "E", "F", "G");
   //after

clang-tools-extra/docs/clang-tidy/checks/abseil-str-cat-append.rst

@@ -3,7 +3,7 @@
 abseil-str-cat-append
 =====================
 
-Flags uses of ``absl::StrCat()`` to append to a ``std::string``. Suggests 
+Flags uses of ``absl::StrCat()`` to append to a ``std::string``. Suggests
 ``absl::StrAppend()`` should be used instead.
 
 The extra calls cause unnecessary temporary strings to be constructed. Removing

clang-tools-extra/docs/clang-tidy/checks/bugprone-bad-signal-to-kill-thread.rst

@@ -3,8 +3,8 @@
 bugprone-bad-signal-to-kill-thread
 ==================================
 
-Finds ``pthread_kill`` function calls when a thread is terminated by 
-raising ``SIGTERM`` signal and the signal kills the entire process, not 
+Finds ``pthread_kill`` function calls when a thread is terminated by
+raising ``SIGTERM`` signal and the signal kills the entire process, not
 just the individual thread. Use any signal except ``SIGTERM``.
 
 .. code-block: c++

clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst

@@ -128,5 +128,5 @@ Options
 .. option::  WantToUseSafeFunctions
 
    The value `true` specifies that the target environment is considered to
-   implement '_s' suffixed memory and string handler functions which are safer 
+   implement '_s' suffixed memory and string handler functions which are safer
    than older versions (e.g. 'memcpy_s()'). The default value is `true`.

clang-tools-extra/docs/clang-tidy/checks/bugprone-reserved-identifier.rst

@@ -5,53 +5,53 @@ bugprone-reserved-identifier
 
 `cert-dcl37-c` and `cert-dcl51-cpp` redirect here as an alias for this check.
 
-Checks for usages of identifiers reserved for use by the implementation. 
+Checks for usages of identifiers reserved for use by the implementation.
 
 The C and C++ standards both reserve the following names for such use:
 
 - identifiers that begin with an underscore followed by an uppercase letter;
 - identifiers in the global namespace that begin with an underscore.
 
 The C standard additionally reserves names beginning with a double underscore,
-while the C++ standard strengthens this to reserve names with a double 
+while the C++ standard strengthens this to reserve names with a double
 underscore occurring anywhere.
 
 Violating the naming rules above results in undefined behavior.
 
 .. code-block:: c++
 
-  namespace NS { 
+  namespace NS {
     void __f(); // name is not allowed in user code
     using _Int = int; // same with this
     #define cool__macro // also this
   }
   int _g(); // disallowed in global namespace only
 
-The check can also be inverted, i.e. it can be configured to flag any 
-identifier that is _not_ a reserved identifier. This mode is for use by e.g. 
-standard library implementors, to ensure they don't infringe on the user 
+The check can also be inverted, i.e. it can be configured to flag any
+identifier that is _not_ a reserved identifier. This mode is for use by e.g.
+standard library implementors, to ensure they don't infringe on the user
 namespace.
 
-This check does not (yet) check for other reserved names, e.g. macro names 
-identical to language keywords, and names specifically reserved by language 
+This check does not (yet) check for other reserved names, e.g. macro names
+identical to language keywords, and names specifically reserved by language
 standards, e.g. C++ 'zombie names' and C future library directions.
 
-This check corresponds to CERT C Coding Standard rule `DCL37-C. Do not declare 
+This check corresponds to CERT C Coding Standard rule `DCL37-C. Do not declare
 or define a reserved identifier
 <https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier>`_
 as well as its C++ counterpart, `DCL51-CPP. Do not declare or define a reserved
-identifier 
+identifier
 <https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier>`_.
 
 Options
 -------
 
 .. option:: Invert
 
-   If `true`, inverts the check, i.e. flags names that are not reserved. 
+   If `true`, inverts the check, i.e. flags names that are not reserved.
    Default is `false`.
 
 .. option:: AllowedIdentifiers
 
-   Semicolon-separated list of names that the check ignores. Default is an 
+   Semicolon-separated list of names that the check ignores. Default is an
    empty list.

clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-handler.rst

@@ -32,6 +32,5 @@ and has an alias name ``cert-sig30-c``.
   assumable that  the reason is that the list was not updated for C11.
   The checker includes ``quick_exit`` in the set of safe functions.
   Functions registered as exit handlers are not checked.
-
-  Default is ``POSIX``.
 
+  Default is ``POSIX``.

clang-tools-extra/docs/clang-tidy/checks/bugprone-spuriously-wake-up-functions.rst

@@ -3,9 +3,9 @@
 bugprone-spuriously-wake-up-functions
 =====================================
 
-Finds ``cnd_wait``, ``cnd_timedwait``, ``wait``, ``wait_for``, or 
+Finds ``cnd_wait``, ``cnd_timedwait``, ``wait``, ``wait_for``, or
 ``wait_until`` function calls when the function is not invoked from a loop
-that checks whether a condition predicate holds or the function has a 
+that checks whether a condition predicate holds or the function has a
 condition parameter.
 
 .. code-block: c++

clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-enum-usage.rst

@@ -5,11 +5,11 @@ bugprone-suspicious-enum-usage
 
 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.
 
-The following cases will be investigated only using :option:`StrictMode`. We 
+The following cases will be investigated only using :option:`StrictMode`. We
 regard the enum as a (suspicious)
 bitmask if the three conditions below are true at the same time:
 
@@ -36,13 +36,13 @@ Examples:
   enum { A, B, C };
   enum { D, E, F = 5 };
   enum { G = 10, H = 11, I = 12 };
-  
+
   unsigned flag;
   flag =
       A |
       H; // OK, disjoint value intervals in the enum types ->probably good use.
   flag = B | F; // Warning, have common values so they are probably misused.
-  
+
   // Case 2:
   enum Bitmask {
     A = 0,
@@ -53,7 +53,7 @@ Examples:
     F = 16,
     G = 31 // OK, real bitmask.
   };
-  
+
   enum Almostbitmask {
     AA = 0,
     BB = 1,
@@ -63,7 +63,7 @@ Examples:
     FF = 16,
     GG // Problem, forgot to initialize.
   };
-  
+
   unsigned flag = 0;
   flag |= E; // OK.
   flag |=

clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-memory-comparison.rst

@@ -16,14 +16,14 @@ properly compare the value representations.
 Objects with the same value may not have the same object representation.
 This may be caused by padding or floating-point types.
 
-See also: 
+See also:
 `EXP42-C. Do not compare padding data
 <https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data>`_
 and
 `FLP37-C. Do not use object representations to compare floating-point values
 <https://wiki.sei.cmu.edu/confluence/display/c/FLP37-C.+Do+not+use+object+representations+to+compare+floating-point+values>`_
 
-This check is also related to and partially overlaps the CERT C++ Coding Standard rules 
+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
 <https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions>`_
 and

clang-tools-extra/docs/clang-tidy/checks/cert-dcl37-c.rst

@@ -6,5 +6,5 @@ cert-dcl37-c
 ============
 
 The cert-dcl37-c check is an alias, please see
-`bugprone-reserved-identifier <bugprone-reserved-identifier.html>`_ for more 
+`bugprone-reserved-identifier <bugprone-reserved-identifier.html>`_ for more
 information.

clang-tools-extra/docs/clang-tidy/checks/cert-dcl51-cpp.rst

@@ -6,5 +6,5 @@ cert-dcl51-cpp
 ==============
 
 The cert-dcl51-cpp check is an alias, please see
-`bugprone-reserved-identifier <bugprone-reserved-identifier.html>`_ for more 
+`bugprone-reserved-identifier <bugprone-reserved-identifier.html>`_ for more
 information.

clang-tools-extra/docs/clang-tidy/checks/cert-msc51-cpp.rst

@@ -23,7 +23,7 @@ Examples:
     std::mt19937 engine2(1); // Diagnose
     engine1.seed(); // Diagnose
     engine2.seed(1); // Diagnose
-    
+
     std::time_t t;
     engine1.seed(std::time(&t)); // Diagnose, system time might be controlled by user
 

clang-tools-extra/docs/clang-tidy/checks/cert-oop57-cpp.rst

@@ -35,6 +35,6 @@ Options
    `std::memcmp`, `memcmp`, `std::strcmp`, `strcmp`, `strncmp`.
 
 This check corresponds to the CERT C++ Coding Standard rule
-`OOP57-CPP. Prefer special member functions and overloaded operators to C 
+`OOP57-CPP. Prefer special member functions and overloaded operators to C
 Standard Library functions
 <https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions>`_.

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-goto.rst

@@ -6,11 +6,11 @@ cppcoreguidelines-avoid-goto
 The usage of ``goto`` for control flow is error prone and should be replaced
 with looping constructs. Only forward jumps in nested loops are accepted.
 
-This check implements `ES.76 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es76-avoid-goto>`_ 
-from the CppCoreGuidelines and 
+This check implements `ES.76 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es76-avoid-goto>`_
+from the CppCoreGuidelines and
 `6.3.1 from High Integrity C++ <http://www.codingstandard.com/rule/6-3-1-ensure-that-the-labels-for-a-jump-statement-or-a-switch-condition-appear-later-in-the-same-or-an-enclosing-block/>`_.
 
-For more information on why to avoid programming 
+For more information on why to avoid programming
 with ``goto`` you can read the famous paper `A Case against the GO TO Statement. <https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF>`_.
 
 The check diagnoses ``goto`` for backward jumps in every language mode. These

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst

@@ -6,7 +6,7 @@ cppcoreguidelines-macro-usage
 Finds macro usage that is considered problematic because better language
 constructs exist for the task.
 
-The relevant sections in the C++ Core Guidelines are 
+The relevant sections in the C++ Core Guidelines are
 `Enum.1 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#enum1-prefer-enumerations-over-macros>`_,
 `ES.30 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es30-dont-use-macros-for-program-text-manipulation>`_,
 `ES.31 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es31-dont-use-macros-for-constants-or-functions>`_ and
@@ -17,7 +17,7 @@ Options
 
 .. option:: AllowedRegexp
 
-    A regular expression to filter allowed macros. For example 
+    A regular expression to filter allowed macros. For example
     `DEBUG*|LIBTORRENT*|TORRENT*|UNI*` could be applied to filter `libtorrent`.
     Default value is `^DEBUG_*`.
 

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-no-malloc.rst

@@ -6,7 +6,7 @@ cppcoreguidelines-no-malloc
 This check handles C-Style memory management using ``malloc()``, ``realloc()``,
 ``calloc()`` and ``free()``. It warns about its use and tries to suggest the use
 of an appropriate RAII object.
-Furthermore, it can be configured to check against a user-specified list of functions 
+Furthermore, it can be configured to check against a user-specified list of functions
 that are used for memory management (e.g. ``posix_memalign()``).
 See `C++ Core Guidelines <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rr-mallocfree>`_.
 
@@ -31,16 +31,15 @@ Options
 
 .. option:: Allocations
 
-   Semicolon-separated list of fully qualified names of memory allocation functions. 
+   Semicolon-separated list of fully qualified names of memory allocation functions.
    Defaults to ``::malloc;::calloc``.
 
 .. option:: Deallocations
 
-   Semicolon-separated list of fully qualified names of memory allocation functions. 
+   Semicolon-separated list of fully qualified names of memory allocation functions.
    Defaults to ``::free``.
 
 .. option:: Reallocations
 
-   Semicolon-separated list of fully qualified names of memory allocation functions. 
+   Semicolon-separated list of fully qualified names of memory allocation functions.
    Defaults to ``::realloc``.
-

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-owning-memory.rst

@@ -3,8 +3,8 @@
 cppcoreguidelines-owning-memory
 ===============================
 
-This check implements the type-based semantics of ``gsl::owner<T*>``, which allows 
-static analysis on code, that uses raw pointers to handle resources like 
+This check implements the type-based semantics of ``gsl::owner<T*>``, which allows
+static analysis on code, that uses raw pointers to handle resources like
 dynamic memory, but won't introduce RAII concepts.
 
 The relevant sections in the `C++ Core Guidelines <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md>`_ are I.11, C.33, R.3 and GSL.Views
@@ -20,7 +20,7 @@ the `Guideline Support Library <https://github.com/isocpp/CppCoreGuidelines/blob
 All checks are purely type based and not (yet) flow sensitive.
 
 The following examples will demonstrate the correct and incorrect initializations
-of owners, assignment is handled the same way. Note that both ``new`` and 
+of owners, assignment is handled the same way. Note that both ``new`` and
 ``malloc()``-like resource functions are considered to produce resources.
 
 .. code-block:: c++
@@ -53,7 +53,7 @@ to be deleted.
   // Example Good, Ownership correctly stated
   gsl::owner<int*> Owner = new int(42); // Good
   delete Owner; // Good as well, statically enforced, that only owners get deleted
-  
+
 The check will furthermore ensure, that functions, that expect a ``gsl::owner<T*>`` as
 argument get called with either a ``gsl::owner<T*>`` or a newly created resource.
 
@@ -100,7 +100,7 @@ Options
 Limitations
 -----------
 
-Using ``gsl::owner<T*>`` in a typedef or alias is not handled correctly. 
+Using ``gsl::owner<T*>`` in a typedef or alias is not handled correctly.
 
 .. code-block:: c++
 
@@ -110,7 +110,7 @@ Using ``gsl::owner<T*>`` in a typedef or alias is not handled correctly.
 The ``gsl::owner<T*>`` is declared as a templated type alias.
 In template functions and classes, like in the example below, the information
 of the type aliases gets lost. Therefore using ``gsl::owner<T*>`` in a heavy templated
-code base might lead to false positives. 
+code base might lead to false positives.
 
 Known code constructs that do not get diagnosed correctly are:
 
@@ -127,7 +127,7 @@ Known code constructs that do not get diagnosed correctly are:
 
   gsl::owner<int*> function_that_returns_owner() { return gsl::owner<int*>(new int(42)); }
 
-  // Type deduction does not work for auto variables. 
+  // Type deduction does not work for auto variables.
   // This is caught by the check and will be noted accordingly.
   auto OwnedObject = function_that_returns_owner(); // Type of OwnedObject will be int*
 
@@ -152,25 +152,25 @@ Known code constructs that do not get diagnosed correctly are:
   };
 
   // Code, that yields a false positive.
-  OwnedValue<gsl::owner<int*>> Owner(new int(42)); // Type deduction yield T -> int * 
+  OwnedValue<gsl::owner<int*>> Owner(new int(42)); // Type deduction yield T -> int *
   // False positive, getValue returns int* and not gsl::owner<int*>
-  gsl::owner<int*> OwnedInt = Owner.getValue(); 
+  gsl::owner<int*> OwnedInt = Owner.getValue();
 
 Another limitation of the current implementation is only the type based checking.
 Suppose you have code like the following:
 
 .. code-block:: c++
 
   // Two owners with assigned resources
-  gsl::owner<int*> Owner1 = new int(42); 
+  gsl::owner<int*> Owner1 = new int(42);
   gsl::owner<int*> Owner2 = new int(42);
 
   Owner2 = Owner1; // Conceptual Leak of initial resource of Owner2!
   Owner1 = nullptr;
 
 The semantic of a ``gsl::owner<T*>`` is mostly like a ``std::unique_ptr<T>``, therefore
-assignment of two ``gsl::owner<T*>`` is considered a move, which requires that the 
+assignment of two ``gsl::owner<T*>`` is considered a move, which requires that the
 resource ``Owner2`` must have been released before the assignment.
-This kind of condition could be caught in later improvements of this check with 
+This kind of condition could be caught in later improvements of this check with
 flowsensitive analysis. Currently, the `Clang Static Analyzer` catches this bug
 for dynamic memory, but not for general types of resources.