[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,7 +5,7 @@ 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:
 
@@ -13,34 +13,34 @@ The C and C++ standards both reserve the following names for such use:
 - 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
@@ -48,10 +48,10 @@ 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,9 +152,9 @@ 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:
@@ -162,15 +162,15 @@ 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.

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-special-member-functions.rst

@@ -27,21 +27,21 @@ Options
 
    When set to `true` (default is `false`), this check doesn't flag classes with a sole, explicitly
    defaulted destructor. An example for such a class is:
-   
+
    .. code-block:: c++
-   
+
      struct A {
        virtual ~A() = default;
      };
-   
+
 .. option:: AllowMissingMoveFunctions
 
    When set to `true` (default is `false`), this check doesn't flag classes which define no move
    operations at all. It still flags classes which define only one of either
    move constructor or move assignment operator. With this option enabled, the following class won't be flagged:
-   
+
    .. code-block:: c++
-   
+
      struct A {
        A(const A&);
        A& operator=(const A&);
@@ -52,11 +52,11 @@ Options
 
    When set to `true` (default is `false`), this check doesn't flag classes which define deleted copy
    operations but don't define move operations. This flag is related to Google C++ Style Guide
-   https://google.github.io/styleguide/cppguide.html#Copyable_Movable_Types. With this option enabled, the 
+   https://google.github.io/styleguide/cppguide.html#Copyable_Movable_Types. With this option enabled, the
    following class won't be flagged:
-   
+
    .. code-block:: c++
-   
+
      struct A {
        A(const A&) = delete;
        A& operator=(const A&) = delete;

clang-tools-extra/docs/clang-tidy/checks/darwin-avoid-spinlock.rst

@@ -4,7 +4,7 @@ darwin-avoid-spinlock
 =====================
 
 Finds usages of ``OSSpinlock``, which is deprecated due to potential livelock
-problems. 
+problems.
 
 This check will detect following function invocations:
 

clang-tools-extra/docs/clang-tidy/checks/fuchsia-overloaded-operator.rst

@@ -3,7 +3,7 @@
 fuchsia-overloaded-operator
 ===========================
 
-Warns if an operator is overloaded, except for the assignment (copy and move) 
+Warns if an operator is overloaded, except for the assignment (copy and move)
 operators.
 
 For example: