Replace references to "transform" with references to "check" where neccessary in the documentation.

[angelgarcia]

Summary

Replace references to "transform" with references to "check" where neccessary in the documentation.

[alexfh]

Thanks! LG with a couple of nits.

docs/clang-tidy/checks/modernize-pass-by-value.rst

4–5

2gqj

docs/clang-tidy/checks/modernize-replace-auto-ptr.rst

34–35

One "the" too much. Also 2gqj

docs/clang-tidy/checks/modernize-use-auto.rst

54–55

gqj

58

Add an empty line above, otherwise this line doesn't get recognized as a list item.

60

Please try removing the empty lines between these list items to make it easier to see the whole list.

112–113

gqj

[angelgarcia]

Done.

docs/clang-tidy/checks/modernize-loop-convert.rst

.. code-block:: c++
 
   const int N = 5;
   int arr[] = {1,2,3,4,5};
   vector<int> v;
   v.push_back(1);
   v.push_back(2);
   v.push_back(3);
 
-  // safe transform
+  // safe conversion
   for (int i = 0; i < N; ++i)
     cout << arr[i];
 
-  // reasonable transform
+  // reasonable conversion
   for (vector<int>::iterator it = v.begin(); it != v.end(); ++it)
     cout << *it;*
 
-  // reasonable transform
+  // reasonable conversion
   for (int i = 0; i < v.size(); ++i)
     cout << v[i];
 
-After transformation with confidence level set to ``reasonable`` (default):
+After applying the check with minimum confidence level set to ``reasonable`` (default):
 
 .. code-block:: c++
 
   const int N = 5;
   int arr[] = {1,2,3,4,5};
   vector<int> v;
   v.push_back(1);
   v.push_back(2);
   v.push_back(3);
 
-  // safe transform
+  // safe conversion
   for (auto & elem : arr)
     cout << elem;
 
-  // reasonable transform
+  // reasonable conversion
   for (auto & elem : v)
     cout << elem;
 
-  // reasonable transform
+  // reasonable conversion
   for (auto & elem : v)
     cout << elem;
 
 Limitations
 ===========
 
 There are certain situations where the tool may erroneously perform
 transformations that remove information and change semantics. Users of the tool
-should be aware of the behaviour and limitations of the transform outlined by
+should be aware of the behaviour and limitations of the check outlined by
 the cases below.
 
 Comments inside loop headers
 ----------------------------
 
 Comments inside the original loop header are ignored and deleted when
 transformed.
 
.. code-block:: c++
   // Will be transformed to:
   for (auto & elem : c) {
     elem.func(); // No longer using operator->()
   }
 
 Pointers and references to containers
 -------------------------------------
 
-While most of the transform's risk analysis is dedicated to determining whether
+While most of the check's risk analysis is dedicated to determining whether
 the iterator or container was modified within the loop, it is possible to
 circumvent the analysis by accessing and modifying the container through a
 pointer or reference.
 
 If the container were directly used instead of using the pointer or reference
 the following transformation would have only been applied at the ``risky``
 level since calling a member function of the container is considered `risky`.
-The transform cannot identify expressions associated with the container that are
+The check cannot identify expressions associated with the container that are
 different than the one used in the loop header, therefore the transformation
 below ends up being performed at the ``safe`` level.
 
 .. code-block:: c++
 
   vector<int> vec;
 
   vector<int> *ptr = &vec;

docs/clang-tidy/checks/modernize-pass-by-value.rst

 modernize-pass-by-value
 =======================
 
 With move semantics added to the language and the standard library updated with
-move constructors added for many types it is now interesting to take an argument
-directly by value, instead of by const-reference, and then copy. This
-transformation allows the compiler to take care of choosing the best way to
-construct the copy.
+move constructors added for many types it is now interesting to take an
+argument directly by value, instead of by const-reference, and then copy. This
+check allows the compiler to take care of choosing the best way to construct
+the copy.
 
 The transformation is usually beneficial when the calling code passes an
 *rvalue* and assumes the move construction is a cheap operation. This short
 example illustrates how the construction of the value happens:
 
   .. code-block:: c++
 
     void foo(std::string s);

 
 Pass-by-value in constructors
 -----------------------------
 
 Replaces the uses of const-references constructor parameters that are copied
 into class fields. The parameter is then moved with `std::move()`.
 
 Since `std::move()` is a library function declared in `<utility>` it may be
-necessary to add this include. The transform will add the include directive when
+necessary to add this include. The check will add the include directive when
 necessary.
 
   .. code-block:: c++
 
      #include <string>
 
      class Foo {
      public:

docs/clang-tidy/checks/modernize-replace-auto-ptr.rst

.. code-block:: c++
 
   -  b = a;
   -  take_ownership_fn(b);
   +  b = std::move(a);
   +  take_ownership_fn(std::move(b));
    }
 
 Since `std::move()` is a library function declared in `<utility>` it may be
-necessary to add this include. The transform will add the include directive when
+necessary to add this include. The check will add the include directive when
 necessary.
 
 Known Limitations
 =================
 * If headers modification is not activated or if a header is not allowed to be
-  changed this transform will produce broken code (compilation error), where the
-  the headers' code will stay unchanged while the code using them will be
-  changed.
-
-* Client code that declares a reference to an ``std::auto_ptr`` coming from code
-  that can't be migrated (such as a header coming from a 3\ :sup:`rd` party
-  library) will produce a compilation error after migration. This is because the
-  type of the reference will be changed to ``std::unique_ptr`` but the type
-  returned by the library won't change, binding a reference to
+  changed this check will produce broken code (compilation error), where the
+  headers' code will stay unchanged while the code using them will be changed.
+
+* Client code that declares a reference to an ``std::auto_ptr`` coming from
+  code that can't be migrated (such as a header coming from a 3\ :sup:`rd`
+  party library) will produce a compilation error after migration. This is
+  because the type of the reference will be changed to ``std::unique_ptr`` but
+  the type returned by the library won't change, binding a reference to
   ``std::unique_ptr`` from an ``std::auto_ptr``. This pattern doesn't make much
-  sense and usually ``std::auto_ptr`` are stored by value (otherwise what is the
-  point in using them instead of a reference or a pointer?).
+  sense and usually ``std::auto_ptr`` are stored by value (otherwise what is
+  the point in using them instead of a reference or a pointer?).
 
   .. code-block:: c++
 
      // <3rd-party header...>
      std::auto_ptr<int> get_value();
      const std::auto_ptr<int> & get_ref();
 
      // <calling code (with migration)...>

docs/clang-tidy/checks/modernize-use-auto.rst

 modernize-use-auto
 ==================
 
-This check is responsible for using the ``auto`` type specifier for
-variable declarations to *improve code readability and maintainability*.
-For example:
+This check is responsible for using the ``auto`` type specifier for variable
+declarations to *improve code readability and maintainability*.  For example:
 
 .. code-block:: c++
 
   std::vector<int>::iterator I = my_container.begin();
 
   // transforms to:
 
   auto I = my_container.begin();

 and maintainability. As a result, ``auto`` is used only introduced in specific
 situations described below.
 
 Iterators
 =========
 
 Iterator type specifiers tend to be long and used frequently, especially in
 loop constructs. Since the functions generating iterators have a common format,
-the type specifier can be replaced without obscuring the meaning of code while 
+the type specifier can be replaced without obscuring the meaning of code while
 improving readability and maintainability.
 
 .. code-block:: c++
 
   for (std::vector<int>::iterator I = my_container.begin(),
                                   E = my_container.end();
        I != E; ++I) {
   }
 
   // becomes
 
   for (auto I = my_container.begin(), E = my_container.end(); I != E; ++I) {
   }
 
-The transform will only replace iterator type-specifiers when all of the
-following conditions are satisfied:
+The check will only replace iterator type-specifiers when all of the following
+conditions are satisfied:
+
 * The iterator is for one of the standard container in ``std`` namespace:
 
   * ``array``
-
   * ``deque``
-
   * ``forward_list``
-
   * ``list``
-
   * ``vector``
-
   * ``map``
-
   * ``multimap``
-
   * ``set``
-
   * ``multiset``
-
   * ``unordered_map``
-
   * ``unordered_multimap``
-
   * ``unordered_set``
-
   * ``unordered_multiset``
-
   * ``queue``
-
   * ``priority_queue``
-
   * ``stack``
 
 * The iterator is one of the possible iterator types for standard containers:
 
   * ``iterator``
-
   * ``reverse_iterator``
-
   * ``const_iterator``
-
   * ``const_reverse_iterator``
 
 * In addition to using iterator types directly, typedefs or other ways of
   referring to those types are also allowed. However, implementation-specific
   types for which a type like ``std::vector<int>::iterator`` is itself a
   typedef will not be transformed. Consider the following examples:
 
 .. code-block:: c++
.. code-block:: c++
   // std::vector<int>::iterator could be a typedef would not be transformed.
   __gnu_cxx::__normal_iterator<int*, std::vector> K = MyVec.begin();
 
 * The initializer for the variable being declared is not a braced initializer
   list. Otherwise, use of ``auto`` would cause the type of the variable to be
   deduced as``std::initializer_list``.
 
 Known Limitations
 =================
-* If the initializer is an explicit conversion constructor, the transform will
-  not replace the type specifier even though it would be safe to do so.
+* If the initializer is an explicit conversion constructor, the check will not
+  replace the type specifier even though it would be safe to do so.
+
 * User-defined iterators are not handled at this time.
 

docs/clang-tidy/checks/modernize-use-nullptr.rst

.. code-block:: c++
   int *ret_ptr() {
     return nullptr;
   }
 
 
 User defined macros
 ===================
 
-By default this transform will only replace the ``NULL`` macro and will skip any
+By default this check will only replace the ``NULL`` macro and will skip any
 user-defined macros that behaves like ``NULL``. The user can use the
 :option:``UserNullMacros`` option to specify a comma-separated list of macro
 names that will be transformed along with ``NULL``.
 
 Example
 -------
 
 .. code-block:: c++