[NFC] Tidy up spelling, grammar, and inconsistencies in clang-tidy documentation

[salman-javed-nz]

Summary

• Fix spelling and grammatical mistakes found across the .rst files.

• Standardize to US English spelling for words such as "behavior" and "specialization".

• Remove repeated words, e.g. "for a a larger user input".

• Standardize spelling of "e.g." and "i.e."

• Replace curly quote characters (‘ ’ “ ”) with standard straight ones (' "). Replace en-dash (–) with standard hyphen (-). In both cases, the latter is used more often in the doc files and is easier to type.

• Change double spaces after commas and periods to single space.

• Ensure there is a empty line at the end of each .rst file.

[salman-javed-nz]

Change double spaces after commas and periods to single space.

[salman-javed-nz]

Replace curly quote characters (‘ ’ “ ”) with standard straight ones (' ").
Replace en-dash (–) with standard hyphen (-).
In both cases, the latter is used more often in the doc files and is easier to type.

[salman-javed-nz]

Standardize spelling of "e.g." and "i.e."

[salman-javed-nz]

Remove repeated words, e.g. "for a a larger user input".

[salman-javed-nz]

Standardize to US English spelling for words such as "behavior" and "specialization".

[salman-javed-nz]

Fix spelling and grammatical mistakes found across the .rst files.

// end of patch

[salman-javed-nz]

A collection of minor corrections that I don't think deserve separate commits.

It shouldn't take much congitive load to review it all as one patch.
In any case, I have used Phabricator's "Update Revision" feature to break out the change into smaller chunks, so you can easily see the changes at each stage.

[salman-javed-nz]

Pre-merge checks failing because patch cannot be applied.
Therefore recreating patch to fix this.

[kazu]

LGTM. Thanks for fixing the docs!

[salman-javed-nz]

Thanks for the review.
Are you able to commit for me?

Salman Javed <[e-mail]>

Thank you very much.

[carlosgalvezp]

Awesome @salman-javed-nz , thanks for fixing the docs! May I ask how did you create these "smaller commits"? It's very nice to click on each of them and see only what changed. I believe I followed your same procedure (use the "Update Revision" thingy) but it always displays the full commit with all changes, so it's hard to see what each new update did.

[salman-javed-nz]

In D112356#3082084, @carlosgalvezp wrote:

Awesome @salman-javed-nz , thanks for fixing the docs! May I ask how did you create these "smaller commits"? It's very nice to click on each of them and see only what changed. I believe I followed your same procedure (use the "Update Revision" thingy) but it always displays the full commit with all changes, so it's hard to see what each new update did.

I created a patch for each my commits on my local disk like so:

git show HEAD -U999999 > HEAD.patch
git show HEAD~1 -U999999 > HEAD~1.patch
git show HEAD~2 -U999999 > HEAD~2.patch
  (and so on...)

I uploaded them one by one through Phab's web interface. This process is just something I stumbled though myself that worked for me.

I wouldn't be surprised if arcanist has something that makes this easier, but I don't use it so I wouldn't know.

[• Quuxplusone]

Definitely an improvement! I looked at all the changed places and found some more improvements you can make. I don't need to see this again, though.

The only disimprovement I found was "Jaro–Winkler" becoming "Jaro-Winkler".

clang-tools-extra/docs/clang-tidy/Contributing.rst

444–445

Naïve grammar fix:

It may also be necessary to restrict the header files from which warnings are displayed using the ``-header-filter`` flag.

But, better, active-voice fix:

You can also use the ``-header-filter`` flag to silence warnings from certain header files.

clang-tools-extra/docs/clang-tidy/checks/abseil-no-internal-dependencies.rst

9

What is "you mention it"? Should this just say "mention it"? but even then, I don't know the technical definition of "mention" in this context.

clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe2.rst

6–7

Should pipe2() and O_CLOEXEC be double-backticked here? I think so.

clang-tools-extra/docs/clang-tidy/checks/boost-use-to-string.rst

10

s/floating points/floating-point types/

clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst

122

s/variants/variants,/

157

This letter is at the beginning of a sentence, so E.g. is correct. Arguably. It is a sentence fragment. ;)
Perhaps:

The heuristics suppress the easily-swappable-parameters warning for pairs of parameters that:
* Are used together in the same expression, such as ``f(a, b)`` or ``a < b``.
* Are passed in the same argument position to the same function, such as ``f(a, 1)`` and ``f(b, 1)``, as long as both of those expressions call the same overload ``f(SomeT, int)``.

This section definitely needs better examples.

clang-tools-extra/docs/clang-tidy/checks/bugprone-implicit-widening-of-multiplication-result.rst

11

This is useful mainly when

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

64

Here and line 68: "is could be safe" doesn't make sense, but I'm not sure what is meant. My guess is that the writer is trying to refer to a set of functions, the "could-be-safe functions," like:

If we're in C++, and the new function is a could-be-safe function, and the destination array is...

but I haven't found whether the notion of "could-be-safe" functions is actually defined anywhere.

clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-string-compare.rst

17

Checks that the results of comparison functions (e.g. ``strcmp``) are...

clang-tools-extra/docs/clang-tidy/checks/bugprone-too-small-loop-variable.rst

28–29

The ``doSomething`` function works for ``items.size() < 32767``, but has undefined behavior for larger vectors.

Also, const std::vector& needs to be const std::vector<int>&; CTAD isn't allowed on function parameters.

clang-tools-extra/docs/clang-tidy/checks/concurrency-mt-unsafe.rst

15

Sentence-initial letter should be capitalized. Again, sentence fragment.

Note that using some thread-unsafe functions may be still valid in
concurrent programming if only a single thread is used; for example, ``setenv(3)``.
However, some functions may track global state which
would be clobbered by subsequent (non-parallel, but concurrent) calls to
a related function. For example, the following code suffers from unprotected
accesses to global state:

clang-tools-extra/docs/clang-tidy/checks/hicpp-signed-bitwise.rst

7

implementation-defined

clang-tools-extra/docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst

19

Unicode

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

139

pair. The function

142

s/ranges::reverse_view/std::views::reverse/
C++20 ranges::reverse_view is not a function, and won't (quite) do the right thing (compared to views::reverse) if you pass it something that's already reversed.

clang-tools-extra/docs/clang-tidy/checks/modernize-replace-disallow-copy-and-assign-macro.rst

17

s/a code/code/

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

119

s/improving/to improve/ here and line 152

clang-tools-extra/docs/clang-tidy/checks/openmp-use-default-none.rst

21

clause; no diagnostic. ?

clang-tools-extra/docs/clang-tidy/checks/readability-magic-numbers.rst

12–13

* `C++ Core Guideline ES.45: Avoid "magic constants"; use symbolic constants <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-magic>`_
* `High Integrity C++ Rule 5.1.1: Use symbolic names instead of literal values in code <http://www.codingstandard.com/rule/5-1-1-use-symbolic-names-instead-of-literal-values-in-code/>`_

clang-tools-extra/docs/clang-tidy/checks/readability-suspicious-call-argument.rst

115

Here, "Jaro–Winkler" is correct and "Jaro-Winkler" is wrong.
Ditto "Sørensen–Dice" below.
If there's a markdown equivalent, that still renders an en-dash –, and you want to use that instead, OK. But just changing the punctuation to an ASCII hyphen-dash isn't right. (I notice you didn't change Sørensen to Sorensen, so the goal definitely wasn't a pure ASCII-fication of these files.)

[salman-javed-nz]

In D112356#3082218, @Quuxplusone wrote:

Definitely an improvement! I looked at all the changed places and found some more improvements you can make. I don't need to see this again, though.

Thanks for the suggestions. Good spotting.

My commit was addressing the low hanging fruit - obvious issues like spelling mistakes and missing words.
To get the documentation to a state where it reads well from start to finish will require a deeper inspection, which I am happy to do over the coming days.

clang-tools-extra/docs/clang-tidy/Contributing.rst

 .. _LLVM Coding Standards: https://llvm.org/docs/CodingStandards.html
 .. _LLVM Phabricator: https://llvm.org/docs/Phabricator.html
 
 Next, you need to decide which module the check belongs to. Modules
 are located in subdirectories of `clang-tidy/
 <https://github.com/llvm/llvm-project/tree/main/clang-tools-extra/clang-tidy/>`_
 and contain checks targeting a certain aspect of code quality (performance,
 readability, etc.), certain coding style or standard (Google, LLVM, CERT, etc.)
-or a widely used API (e.g. MPI). Their names are same as user-facing check
-groups names described :ref:`above <checks-groups-table>`.
+or a widely used API (e.g. MPI). Their names are the same as the user-facing
+check group names described :ref:`above <checks-groups-table>`.
 
 After choosing the module and the name for the check, run the
 ``clang-tidy/add_new_check.py`` script to create the skeleton of the check and
 plug it to :program:`clang-tidy`. It's the recommended way of adding new checks.
 
 If we want to create a `readability-awesome-function-names`, we would run:
 
 .. code-block:: console

 * The default set of checks can be overridden using the ``-checks`` argument,
   taking the identical format as :program:`clang-tidy` does. For example
   ``-checks=-*,modernize-use-override`` will run the ``modernize-use-override``
   check only.
 
 * To restrict the files examined you can provide one or more regex arguments
   that the file names are matched against.
   ``run-clang-tidy.py clang-tidy/.*Check\.cpp`` will only analyze clang-tidy
-  checks. It may also be necessary to restrict the header files warnings are
-  displayed from using the ``-header-filter`` flag. It has the same behavior
+  checks. It may also be necessary to restrict the header files that warnings
+  are displayed from using the ``-header-filter`` flag. It has the same behavior
   as the corresponding :program:`clang-tidy` flag.
 
 * To apply suggested fixes ``-fix`` can be passed as an argument. This gathers
   all changes in a temporary directory and applies them. Passing ``-format``
   will run clang-format over changed lines.
 
 
 On checks profiling
===-------------------------------------------------------------------------===
      ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
      0.9136 (100.0%)   0.1146 (100.0%)   1.0282 (100.0%)   1.0258 (100.0%)  readability-function-size
      0.9136 (100.0%)   0.1146 (100.0%)   1.0282 (100.0%)   1.0258 (100.0%)  Total
 
 It can also store that data as JSON files for further processing. Example output:
 
 .. code-block:: console
 
-  $ clang-tidy -enable-check-profile -store-check-profile=.  -checks=-*,readability-function-size source.cpp
+  $ clang-tidy -enable-check-profile -store-check-profile=. -checks=-*,readability-function-size source.cpp
   $ # Note that there won't be timings table printed to the console.
   $ ls /tmp/out/
   20180516161318717446360-source.cpp.json
   $ cat 20180516161318717446360-source.cpp.json
   {
   "file": "/path/to/source.cpp",
   "timestamp": "2018-05-16 16:13:18.717446360",
   "profile": {

clang-tools-extra/docs/clang-tidy/checks/abseil-duration-conversion-cast.rst

.. code-block:: c++
   absl::Duration d;
   double x = static_cast<double>(absl::ToInt64Seconds(d));
 
   // Suggested - Use the integer conversion function directly.
   double x = absl::ToDoubleSeconds(d);
 
 
 Note: In the second example, the suggested fix could yield a different result,
-as the conversion to integer could truncate.  In practice, this is very rare,
+as the conversion to integer could truncate. In practice, this is very rare,
 and you should use ``absl::Trunc`` to perform this operation explicitly instead.

clang-tools-extra/docs/clang-tidy/checks/abseil-no-internal-dependencies.rst

 subl.. title:: clang-tidy - abseil-no-internal-dependencies
 
 abseil-no-internal-dependencies
 ===============================
 
 Warns if code using Abseil depends on internal details. If something is in a
 namespace that includes the word "internal", code is not allowed to depend upon
-it because it’s an implementation detail. They cannot friend it, include it,
+it because it's an implementation detail. They cannot friend it, include it,
 you mention it or refer to it in any way. Doing so violates Abseil's
 compatibility guidelines and may result in breakage. See
 https://abseil.io/about/compatibility for more information.
 
 The following cases will result in warnings:
 
 .. code-block:: c++
 
   absl::strings_internal::foo();
   // warning triggered on this line
   class foo {
     friend struct absl::container_internal::faa;
     // warning triggered on this line
   };
   absl::memory_internal::MakeUniqueResult();
   // warning triggered on this line

clang-tools-extra/docs/clang-tidy/checks/abseil-string-find-str-contains.rst

 .. title:: clang-tidy - abseil-string-find-str-contains
 
 abseil-string-find-str-contains
 ===============================
 
 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.
 
 By default, "string-like types" includes ``::std::basic_string``,
-``::std::basic_string_view``, and ``::absl::string_view``.  See the
+``::std::basic_string_view``, and ``::absl::string_view``. See the
 StringLikeClasses option to change this.
 
 .. code-block:: c++
 
   std::string s = "...";
   if (s.find("Hello World") == std::string::npos) { /* do something */ }
 
   absl::string_view a = "...";

clang-tools-extra/docs/clang-tidy/checks/android-cloexec-open.rst

 .. title:: clang-tidy - android-cloexec-open
 
 android-cloexec-open
 ====================
 
 A common source of security bugs is code that opens a file without using the
-``O_CLOEXEC`` flag.  Without that flag, an opened sensitive file would remain
+``O_CLOEXEC`` flag. Without that flag, an opened sensitive file would remain
 open across a fork+exec to a lower-privileged SELinux domain, leaking that
 sensitive data. Open-like functions including ``open()``, ``openat()``, and
 ``open64()`` should include ``O_CLOEXEC`` in their flags argument.
 
 Examples:
 
 .. code-block:: c++
 

clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe2.rst

 .. title:: clang-tidy - android-cloexec-pipe2
 
 android-cloexec-pipe2
 =====================
 
-This checks ensures that pipe2() is called with the O_CLOEXEC flag. The check also
+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.
 
 Examples:
 
 .. code-block:: c++
 
   pipe2(pipefd, O_NONBLOCK);
 
 Suggested replacement:
 
 .. code-block:: c++
 
   pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);

clang-tools-extra/docs/clang-tidy/checks/boost-use-to-string.rst

 .. title:: clang-tidy - boost-use-to-string
 
 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``.
 
 It doesn't replace conversion from floating points despite the ``to_string``
-overloads, because it would change the behaviour.
+overloads, because it would change the behavior.
 
 
 .. code-block:: c++
 
     auto str = boost::lexical_cast<std::string>(42);
     auto wstr = boost::lexical_cast<std::wstring>(2137LL);
 
     // Will be changed to
     auto str = std::to_string(42);
     auto wstr = std::to_wstring(2137LL);
 

clang-tools-extra/docs/clang-tidy/checks/bugprone-branch-clone.rst

 .. code-block:: c++
 
     return test_value(x) ? x : x;
 
 Unlike if statements, the check does not detect chains of conditional
 operators.
 
 Note: This check also reports situations where branches become identical only
-after preprocession.
+after preprocessing.

clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst

 
 .. option:: IgnoredParameterNames
 
     The list of parameter **names** that should never be considered part of a
     swappable adjacent parameter sequence.
     The value is a `;`-separated list of names.
     To ignore unnamed parameters, add `""` to the list verbatim (not the
     empty string, but the two quotes, potentially escaped!).
-    **This options is case-sensitive!**
+    **This option is case-sensitive!**
 
     By default, the following parameter names, and their Uppercase-initial
     variants are ignored:
     `""` (unnamed parameters), `iterator`, `begin`, `end`, `first`, `last`,
     `lhs`, `rhs`.
 
 .. option:: IgnoredParameterTypeSuffixes
 
     The list of parameter **type name suffixes** that should never be
     considered part of a swappable adjacent parameter sequence.
     Parameters which type, as written in the source code, end with an element
.. option:: SuppressParametersUsedTogether
 
     Currently, the following heuristics are implemented which will suppress the
     warning about the parameter pair involved:
 
     * The parameters are used in the same expression, e.g. ``f(a, b)`` or
       ``a < b``.
     * The parameters are further passed to the same function to the same
       parameter of that function, of the same overload.
-      E.g. ``f(a, 1)`` and ``f(b, 2)`` to some ``f(T, int)``.
+      e.g. ``f(a, 1)`` and ``f(b, 2)`` to some ``f(T, int)``.
 
       .. note::
 
         The check does not perform path-sensitive analysis, and as such,
         "same function" in this context means the same function declaration.
         If the same member function of a type on two distinct instances are
         called with the parameters, it will still be regarded as
         "same function".

 
 The check does not investigate functions that are generated by the compiler
 in a context that is only determined from a call site.
 These cases include variadic functions, functions in C code that do not have
 an argument list, and C++ template instantiations.
 Most of these cases, which are otherwise swappable from a caller's standpoint,
 have no way of getting "fixed" at the definition point.
 In the case of C++ templates, only primary template definitions and explicit
-specialisations are matched and analysed.
+specializations are matched and analyzed.
 
 None of the following cases produce a diagnostic:
 
 .. code-block:: c++
 
     int printf(const char *Format, ...) { /* ... */ }
     int someOldCFunction() { /* ... */ }
 
.. code-block:: c++
     // is the same type.
     void instantiated(int A, Vector<int>::element_type B) { /* ... */ }
 
     // Diagnosed: The two parameter types are exactly the same.
     template <typename T>
     void exact(typename Vector<T>::element_type A,
                typename Vector<T>::element_type B) { /* ... */ }
 
-    // Skipped: The two parameters are both 'T' but we can not prove this
+    // Skipped: The two parameters are both 'T' but we cannot prove this
     // without actually instantiating.
     template <typename T>
     void falseNegative(T A, typename Vector<T>::element_type B) { /* ... */ }
 
 In the context of *implicit conversions* (when `ModelImplicitConversions` is
 enabled), the modelling performed by the check
 warns if the parameters are swappable and the swapped order matches implicit
 conversions.

clang-tools-extra/docs/clang-tidy/checks/bugprone-implicit-widening-of-multiplication-result.rst

 .. title:: clang-tidy - bugprone-implicit-widening-of-multiplication-result
 
 bugprone-implicit-widening-of-multiplication-result
 ===================================================
 
 The check diagnoses instances where a result of a multiplication is implicitly
 widened, and suggests (with fix-it) to either silence the code by making
 widening explicit, or to perform the multiplication in a wider type,
 to avoid the widening afterwards.
 
-This is mainly useful when operating on a very large buffers.
+This is mainly useful when operating on very large buffers.
 For example, consider:
 
 .. code-block:: c++
 
   void zeroinit(char* base, unsigned width, unsigned height) {
     for(unsigned row = 0; row != height; ++row) {
       for(unsigned col = 0; col != width; ++col) {
         char* ptr = base + row * width + col;
         *ptr = 0;
       }
     }
   }
 
-This is fine in general, but iff ``width * height`` overflows,
+This is fine in general, but if ``width * height`` overflows,
 you end up wrapping back to the beginning of ``base``
 instead of processing the entire requested buffer.
 
 Indeed, this only matters for pretty large buffers (4GB+),
 but that can happen very easily for example in image processing,
 where for that to happen you "only" need a ~269MPix image.
 
 

clang-tools-extra/docs/clang-tidy/checks/bugprone-macro-parentheses.rst

 .. title:: clang-tidy - bugprone-macro-parentheses
 
 bugprone-macro-parentheses
 ==========================
 
 
-Finds macros that can have unexpected behaviour due to missing parentheses.
+Finds macros that can have unexpected behavior due to missing parentheses.
 
 Macros are expanded by the preprocessor as-is. As a result, there can be
-unexpected behaviour; operators may be evaluated in unexpected order and
+unexpected behavior; operators may be evaluated in unexpected order and
 unary operators may become binary operators, etc.
 
 When the replacement list has an expression, it is recommended to surround
 it with parentheses. This ensures that the macro result is evaluated
 completely before it is used.
 
 It is also recommended to surround macro arguments in the replacement list
 with parentheses. This ensures that the argument value is calculated
 properly.

clang-tools-extra/docs/clang-tidy/checks/bugprone-misplaced-operator-in-strlen-in-alloc.rst

 .. title:: clang-tidy - bugprone-misplaced-operator-in-strlen-in-alloc
 
 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
+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:
 
 .. code-block:: c
 
     void bad_malloc(char *str) {

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

 .. title:: clang-tidy - bugprone-not-null-terminated-result
 
 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 behaviour when the string is read.
+null terminator it can result in undefined behavior when the string is read.
 
 The following and their respective ``wchar_t`` based functions are checked:
 
 ``memcpy``, ``memcpy_s``, ``memchr``, ``memmove``, ``memmove_s``,
 ``strerror_s``, ``strncmp``, ``strxfrm``
 
 The following is a real-world example where the programmer forgot to increase
 the passed third argument, which is ``size_t length``. That is why the length
- If copy to the destination array cannot overflow [1] the new function should
   be the older copy function (ending with ``cpy``), because it is more
   efficient than the safe version.
 
 - If copy to the destination array can overflow [1] and
   :option:`WantToUseSafeFunctions` is set to `true` and it is possible to
   obtain the capacity of the destination array then the new function could be
   the safe version (ending with ``cpy_s``).
 
-- If the new function is could be safe version and C++ files are analysed and
+- 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.
 
 - 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 *``.
 
 [1] It is possible to overflow:
   - If the capacity of the destination array is unknown.

clang-tools-extra/docs/clang-tidy/checks/bugprone-sizeof-expression.rst

 .. option:: WarnOnSizeOfThis
 
    When `true`, the check will warn on an expression like ``sizeof(this)``.
    Default is `true`.
 
 .. option:: WarnOnSizeOfCompareToConstant
 
    When `true`, the check will warn on an expression like
-   ``sizeof(epxr) <= k`` for a suspicious constant `k` while `k` is `0` or
+   ``sizeof(expr) <= k`` for a suspicious constant `k` while `k` is `0` or
    greater than `0x8000`. Default is `true`.

clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-string-compare.rst

 .. title:: clang-tidy - bugprone-suspicious-string-compare
 
 bugprone-suspicious-string-compare
 ==================================
 
 Find suspicious usage of runtime string comparison functions.
 This check is valid in C and C++.
 
 Checks for calls with implicit comparator and proposed to explicitly add it.
 
 .. code-block:: c++
 
     if (strcmp(...))       // Implicitly compare to zero
     if (!strcmp(...))      // Won't warn
     if (strcmp(...) != 0)  // Won't warn
 
-Checks that compare function results (i,e, ``strcmp``) are compared to valid
+Checks that compare function results (i.e., ``strcmp``) are compared to valid
 constant. The resulting value is
 
 .. code::
 
     <  0    when lower than,
     >  0    when greater than,
     == 0    when equals.
 

clang-tools-extra/docs/clang-tidy/checks/bugprone-too-small-loop-variable.rst

 In a real use case size means a container's size which depends on the user input.
 
 .. code-block:: c++
 
   int doSomething(const std::vector& items) {
     for (short i = 0; i < items.size(); ++i) {}
   }
 
-This algorithm works for small amount of objects, but will lead to freeze for a
+This algorithm works for a small amount of objects, but will lead to freeze for
 a larger user input.
 
 .. option:: MagnitudeBitsUpperLimit
 
   Upper limit for the magnitude bits of the loop variable. If it's set the check
   filters out those catches in which the loop variable's type has more magnitude
   bits as the specified upper limit. The default value is 16.
   For example, if the user sets this option to 31 (bits), then a 32-bit ``unsigned int``
   is ignored by the check, however a 32-bit ``int`` is not (A 32-bit ``signed int``

clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst

 Calls to ``new`` can throw exceptions of type ``std::bad_alloc`` that should
 be handled by the code. Alternatively, the nonthrowing form of ``new`` can be
 used. The check verifies that the exception is handled in the function
 that calls ``new``, unless a nonthrowing version is used or the exception
 is allowed to propagate out of the function (exception handler is checked for
 types ``std::bad_alloc``, ``std::exception``, and catch-all handler).
 The check assumes that any user-defined ``operator new`` is either
 ``noexcept`` or may throw an exception of type ``std::bad_alloc`` (or derived
-from it). Other exception types or exceptions occurring in the objects's
+from it). Other exception types or exceptions occurring in the object's
 constructor are not taken into account.

clang-tools-extra/docs/clang-tidy/checks/bugprone-virtual-near-miss.rst

 .. title:: clang-tidy - bugprone-virtual-near-miss
 
 bugprone-virtual-near-miss
 ==========================
 
-Warn if a function is a near miss (ie. the name is very similar and the function
+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:
 
 .. code-block:: c++
 
   struct Base {
     virtual void func();
   };
 
   struct Derived : Base {
     virtual void funk();
     // warning: 'Derived::funk' has a similar name and the same signature as virtual method 'Base::func'; did you mean to override it?
   };

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

 Similarly, it is unexpected for the postfix operator to return a reference to
 its previous state, and any subsequent modifications would be operating on a
 stale object.
 
 This check corresponds to the CERT C++ Coding Standard recommendation
 DCL21-CPP. Overloaded postfix increment and decrement operators should return a
 const object. However, all of the CERT recommendations have been removed from
 public view, and so their justification for the behavior of this check requires
-an account on their wiki to view.
+an account on their wiki to view.
 

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

 .. title:: clang-tidy - cert-err09-cpp
 .. meta::
    :http-equiv=refresh: 5;URL=misc-throw-by-value-catch-by-reference.html
 
 cert-err09-cpp
 ==============
 
 The cert-err09-cpp check is an alias, please see
 `misc-throw-by-value-catch-by-reference <misc-throw-by-value-catch-by-reference.html>`_
 for more information.
 
 This check corresponds to the CERT C++ Coding Standard recommendation
 ERR09-CPP. Throw anonymous temporaries. However, all of the CERT recommendations
 have been removed from public view, and so their justification for the behavior
-of this check requires an account on their wiki to view.
+of this check requires an account on their wiki to view.
 

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

 .. title:: clang-tidy - cert-oop11-cpp
 .. meta::
    :http-equiv=refresh: 5;URL=performance-move-constructor-init.html
 
 cert-oop11-cpp
 ==============
 
 The cert-oop11-cpp check is an alias, please see
 `performance-move-constructor-init <performance-move-constructor-init.html>`_
 for more information.
 
 This check corresponds to the CERT C++ Coding Standard recommendation
 OOP11-CPP. Do not copy-initialize members or base classes from a move
 constructor. However, all of the CERT recommendations have been removed from
 public view, and so their justification for the behavior of this check requires
-an account on their wiki to view.
+an account on their wiki to view.
 

clang-tools-extra/docs/clang-tidy/checks/concurrency-mt-unsafe.rst

 .. title:: clang-tidy - concurrency-mt-unsafe
 
 concurrency-mt-unsafe
 =====================
 
 Checks for some thread-unsafe functions against a black list of
 known-to-be-unsafe functions. Usually they access static variables without
 synchronization (e.g. gmtime(3)) or utilize signals in a racy way.
 The set of functions to check is specified with the `FunctionSet` option.
 
 Note that using some thread-unsafe functions may be still valid in
 concurrent programming if only a single thread is used (e.g. setenv(3)),
 however, some functions may track a state in global variables which
 would be clobbered by subsequent (non-parallel, but concurrent) calls to
-a related function. E.g. the following code suffers from unprotected
+a related function. e.g. the following code suffers from unprotected
 accesses to a global state:
 
 .. code-block:: c++
 
     // getnetent(3) maintains global state with DB connection, etc.
     // If a concurrent green thread calls getnetent(3), the global state is corrupted.
     netent = getnetent();
     yield();

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst

 .. title:: clang-tidy - cppcoreguidelines-init-variables
 
 cppcoreguidelines-init-variables
 ================================
 
 Checks whether there are local variables that are declared without an initial
-value. These may lead to unexpected behaviour if there is a code path that reads
+value. These may lead to unexpected behavior if there is a code path that reads
 the variable before assigning to it.
 
 Only integers, booleans, floats, doubles and pointers are checked. The fix
 option initializes all detected values with the value of zero. An exception is
 float and double types, which are initialized to NaN.
 
 As an example a function that looks like this:
 

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst

 
 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 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
+integer to signed integer. Clang's implementation uses the two's complement
 format.

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

struct A {
        A(const A&);
        A& operator=(const A&);
        ~A();
      };
 
 .. option:: AllowMissingMoveFunctionsWhenCopyIsDeleted
 
    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 flags is related to Google C++ Style Guide
+   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 
    following class won't be flagged:
    
    .. code-block:: c++
    
      struct A {
        A(const A&) = delete;
        A& operator=(const A&) = delete;
        ~A();
      };

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-virtual-class-destructor.rst

 .. title:: clang-tidy - cppcoreguidelines-virtual-class-destructor
 
 cppcoreguidelines-virtual-class-destructor
 ===============================================
 
 Finds virtual classes whose destructor is neither public and virtual
 nor protected and non-virtual. A virtual class's destructor should be specified
-in one of these ways to prevent undefined behaviour.
+in one of these ways to prevent undefined behavior.
 
 This check implements
 `C.35 <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual>`_
 from the CppCoreGuidelines.
 
 Note that this check will diagnose a class with a virtual method regardless of
 whether the class is used as a base class or not.
 

clang-tools-extra/docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst

 Degenerated ``switch`` statements without any labels are caught as well.
 
 .. code-block:: c++
 
   // Degenerated switch that could be better written as `if`
   int i = 42;
   switch(i) {
     case 1: // do something here
-    default: // do somethe else here
+    default: // do something else here
   }
 
   // Should rather be the following:
   if (i == 1) { 
     // do something here 
   }
   else { 
     // do something here 

clang-tools-extra/docs/clang-tidy/checks/hicpp-signed-bitwise.rst

 .. title:: clang-tidy - hicpp-signed-bitwise
 
 hicpp-signed-bitwise
 ====================
 
 Finds uses of bitwise operations on signed integer types, which may lead to 
-undefined or implementation defined behaviour.
+undefined or implementation defined behavior.
 
 The according rule is defined in the `High Integrity C++ Standard, Section 5.6.1 <http://www.codingstandard.com/section/5-6-shift-operators/>`_.
 
 Options
 -------
 
 .. option:: IgnorePositiveIntegerLiterals
 
    If this option is set to `true`, the check will not warn on bitwise operations with positive integer literals, e.g. `~0`, `2 << 1`, etc.
    Default value is `false`.

clang-tools-extra/docs/clang-tidy/checks/misc-static-assert.rst

 .. title:: clang-tidy - misc-static-assert
 
 misc-static-assert
 ==================
 
 `cert-dcl03-c` redirects here as an alias for this check.
 
-Replaces ``assert()`` with ``static_assert()`` if the condition is evaluatable
+Replaces ``assert()`` with ``static_assert()`` if the condition is evaluable
 at compile time.
 
 The condition of ``static_assert()`` is evaluated at compile time which is
 safer and more efficient.

clang-tools-extra/docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst

 .. title:: clang-tidy - misc-throw-by-value-catch-by-reference
 
 misc-throw-by-value-catch-by-reference
 ======================================
 
 `cert-err09-cpp` redirects here as an alias for this check.
 `cert-err61-cpp` redirects here as an alias for this check.
 
 Finds violations of the rule "Throw by value, catch by reference" presented for
 example in "C++ Coding Standards" by H. Sutter and A. Alexandrescu, as well as
 the CERT C++ Coding Standard rule `ERR61-CPP. Catch exceptions by lvalue reference
 <https://wiki.sei.cmu.edu/confluence/display/cplusplus/ERR61-CPP.+Catch+exceptions+by+lvalue+reference>`_.
 
 
 Exceptions:
   * Throwing string literals will not be flagged despite being a pointer. They
-    are not susceptible to slicing and the usage of string literals is idomatic.
+    are not susceptible to slicing and the usage of string literals is
+    idiomatic.
   * Catching character pointers (``char``, ``wchar_t``, unicode character types)
     will not be flagged to allow catching sting literals.
   * Moved named values will not be flagged as not throwing an anonymous
     temporary. In this case we can be sure that the user knows that the object
     can't be accessed outside catch blocks handling the error.
   * Throwing function parameters will not be flagged as not throwing an
     anonymous temporary. This allows helper functions for throwing.
-  * Re-throwing caught exception variables will not be flragged as not throwing
+  * Re-throwing caught exception variables will not be flagged as not throwing
     an anonymous temporary. Although this can usually be done by just writing
     ``throw;`` it happens often enough in real code.
 
 Options
 -------
 
 .. option:: CheckThrowTemporaries
 

clang-tools-extra/docs/clang-tidy/checks/modernize-avoid-bind.rst

 .. code-block:: c++
 
   int add(int x, int y) { return x + y; }
   int foo() {
     std::function<int(int,int)> ignore_args = [] { return add(2, 2); }
     return ignore_args(3, 3);
   }
 
-which will *not* compile, since the lambda does not contain an ``operator()`` that
+which will *not* compile, since the lambda does not contain an ``operator()``
 that accepts 2 arguments. With permissive parameter list, it instead generates
 
 .. code-block:: c++
 
   int add(int x, int y) { return x + y; }
   int foo() {
     std::function<int(int,int)> ignore_args = [](auto&&...) { return add(2, 2); }
     return ignore_args(3, 3);
   }
 
 which is correct.
   
 This check requires using C++14 or higher to run.

clang-tools-extra/docs/clang-tidy/checks/modernize-avoid-c-arrays.rst

inline void bar() {
     {
       int j[j[0]]; // not diagnosed
     }
   }
 
   }
 
 Similarly, the ``main()`` function is ignored. Its second and third parameters
-can be either ``char* argv[]`` or ``char** argv``, but can not be
+can be either ``char* argv[]`` or ``char** argv``, but cannot be
 ``std::array<>``.

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

 .. option:: UseCxx20ReverseRanges
   
    When set to true convert loops when in C++20 or later mode using 
    ``std::ranges::reverse_view``.
    Default value is ``true``.
 
 .. option:: MakeReverseRangeFunction
 
    Specify the function used to reverse an iterator pair, the function should 
    accept a class with ``rbegin`` and ``rend`` methods and return a 
-   class with ``begin`` and ``end`` methods methods that call the ``rbegin`` and
+   class with ``begin`` and ``end`` methods that call the ``rbegin`` and
    ``rend`` methods respectively. Common examples are ``ranges::reverse_view``
    and ``llvm::reverse``.
    Default value is an empty string.
 
 .. option:: MakeReverseRangeHeader
 
    Specifies the header file where :option:`MakeReverseRangeFunction` is
    declared. For the previous examples this option would be set to 
    ``range/v3/view/reverse.hpp`` and ``llvm/ADT/STLExtras.h`` respectively.
.. option:: IncludeStyle
    A string specifying which include-style is used, `llvm` or `google`. Default
    is `llvm`.
 
 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 check outlined by
+should be aware of the behavior 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.
 
if (!flag) {
       flag = true;
     }
   }
 
 OpenMP
 ^^^^^^
 
 As range-based for loops are only available since OpenMP 5, this check should
-not been used on code with a compatibility requirements of OpenMP prior to
+not be used on code with a compatibility requirement of OpenMP prior to
 version 5. It is **intentional** that this check does not make any attempts to
 exclude incorrect diagnostics on OpenMP for loops prior to OpenMP 5.
 
 To prevent this check to be applied (and to break) OpenMP for loops but still be
 applied to non-OpenMP for loops the usage of ``NOLINT`` (see
 :ref:`clang-tidy-nolint`) on the specific for loops is recommended.

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

 
 Note about delayed template parsing
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When delayed template parsing is enabled, constructors part of templated
 contexts; templated constructors, constructors in class templates, constructors
 of inner classes of template classes, etc., are not transformed. Delayed
 template parsing is enabled by default on Windows as a Microsoft extension:
-`Clang Compiler User’s Manual - Microsoft extensions`_.
+`Clang Compiler User's Manual - Microsoft extensions`_.
 
 Delayed template parsing can be enabled using the `-fdelayed-template-parsing`
 flag and disabled using `-fno-delayed-template-parsing`.
 
 Example:
 
 .. code-block:: c++
 
    template <typename T> class C {
      std::string S;
 
    public:
  =  // using -fdelayed-template-parsing (default on Windows)
  =  C(const std::string &S) : S(S) {}
 
  +  // using -fno-delayed-template-parsing (default on non-Windows systems)
  +  C(std::string S) : S(std::move(S)) {}
    };
 
-.. _Clang Compiler User’s Manual - Microsoft extensions: https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
+.. _Clang Compiler User's Manual - Microsoft extensions: https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
 
 .. seealso::
 
   For more information about the pass-by-value idiom, read: `Want Speed? Pass by Value`_.
 
   .. _Want Speed? Pass by Value: https://web.archive.org/web/20140205194657/http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
 
 Options

clang-tools-extra/docs/clang-tidy/checks/modernize-replace-disallow-copy-and-assign-macro.rst

 .. title:: clang-tidy - modernize-replace-disallow-copy-and-assign-macro
 
 modernize-replace-disallow-copy-and-assign-macro
 ================================================
 
 Finds macro expansions of ``DISALLOW_COPY_AND_ASSIGN(Type)`` and replaces them
 with a deleted copy constructor and a deleted assignment operator.
 
 Before the ``delete`` keyword was introduced in C++11 it was common practice to
-declare a copy constructor and an assignment operator as a private members. This
+declare a copy constructor and an assignment operator as private members. This
 effectively makes them unusable to the public API of a class.
 
 With the advent of the ``delete`` keyword in C++11 we can abandon the
 ``private`` access of the copy constructor and the assignment operator and
 delete the methods entirely.
 
 When running this check on a code like this:
 
 .. code-block:: c++
 
   class Foo {
   private:
     DISALLOW_COPY_AND_ASSIGN(Foo);
   };
 

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

.. code-block:: c++
   // becomes
 
   for (auto I = my_container.begin(), E = my_container.end(); I != E; ++I) {
   }
 
 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:
+* The iterator is for one of the standard containers in ``std`` namespace:
 
   * ``array``
   * ``deque``
   * ``forward_list``
   * ``list``
   * ``vector``
   * ``map``
   * ``multimap``
* 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``.
 
 New expressions
 ---------------
 
 Frequently, when a pointer is declared and initialized with ``new``, the
 pointee type is written twice: in the declaration type and in the
-``new`` expression. In this cases, the declaration type can be replaced with
+``new`` expression. In this case, the declaration type can be replaced with
 ``auto`` improving readability and maintainability.
 
 .. code-block:: c++
 
   TypeName *my_pointer = new TypeName(my_param);
 
   // becomes
 
   auto *my_pointer = new TypeName(my_param);
.. code-block:: c++
 
   auto *my_first_pointer = new TypeName, *my_second_pointer = new TypeName;
 
 Cast expressions
 ----------------
 
 Frequently, when a variable is declared and initialized with a cast, the
 variable type is written twice: in the declaration type and in the
-cast expression. In this cases, the declaration type can be replaced with
+cast expression. In this case, the declaration type can be replaced with
 ``auto`` improving readability and maintainability.
 
 .. code-block:: c++
 
   TypeName *my_pointer = static_cast<TypeName>(my_param);
 
   // becomes
 
   auto *my_pointer = static_cast<TypeName>(my_param);
 
 The check handles ``static_cast``, ``dynamic_cast``, ``const_cast``,
 ``reinterpret_cast``, functional casts, C-style casts and function templates
 that behave as casts, such as ``llvm::dyn_cast``, ``boost::lexical_cast`` and
-``gsl::narrow_cast``.  Calls to function templates are considered to behave as
+``gsl::narrow_cast``. Calls to function templates are considered to behave as
 casts if the first template argument is explicit and is a type, and the function
 returns that type, or a pointer or reference to it.
 
 Known Limitations
 -----------------
 
 * 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.

clang-tools-extra/docs/clang-tidy/checks/modernize-use-default-member-init.rst

.. note::
   The `readability-redundant-member-init` check will remove redundant member
   initializers for classes.
 
 Options
 -------
 
 .. option:: UseAssignment
 
-   If this option is set to `true` (default is `false`), the check will initialise
+   If this option is set to `true` (default is `false`), the check will initialize
    members with an assignment. For example:
 
 .. code-block:: c++
 
   struct A {
     A() {}
     A(int i) : i(i) {}
     int i = 5;
     double j = 10.0;
   };
 
 .. option:: IgnoreMacros
 
    If this option is set to `true` (default is `true`), the check will not warn
    about members declared inside macros.

clang-tools-extra/docs/clang-tidy/checks/modernize-use-noexcept.rst

 .. title:: clang-tidy - modernize-use-noexcept
 
 modernize-use-noexcept
 ======================
 
 This check replaces deprecated dynamic exception specifications with
-the appropriate noexcept specification (introduced in C++11).  By
+the appropriate noexcept specification (introduced in C++11). By
 default this check will replace ``throw()`` with ``noexcept``,
 and ``throw(<exception>[,...])`` or ``throw(...)`` with
 ``noexcept(false)``.
 
 Example
 -------
 
 .. code-block:: c++
.. code-block:: c++
   void bar() noexcept(false) {}
 
 Options
 -------
 
 .. option:: ReplacementString
 
   Users can use :option:`ReplacementString` to specify a macro to use
-  instead of ``noexcept``.  This is useful when maintaining source code
+  instead of ``noexcept``. This is useful when maintaining source code
   that uses custom exception specification marking other than
-  ``noexcept``.  Fix-it hints will only be generated for non-throwing
+  ``noexcept``. Fix-it hints will only be generated for non-throwing
   specifications.
 
 Example
 ^^^^^^^
 
 .. code-block:: c++
 
   void bar() throw(int);

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

 .. title:: clang-tidy - modernize-use-nullptr
 
 modernize-use-nullptr
 =====================
 
-The check converts the usage of null pointer constants (eg. ``NULL``, ``0``)
+The check converts the usage of null pointer constants (e.g. ``NULL``, ``0``)
 to use the new C++11 ``nullptr`` keyword.
 
 Example
 -------
 
 .. code-block:: c++
 
   void assignment() {

clang-tools-extra/docs/clang-tidy/checks/objc-nsinvocation-argument-lifetime.rst

 .. title:: clang-tidy - objc-nsinvocation-argument-lifetime
 
 objc-nsinvocation-argument-lifetime
 ===================================
 
 Finds calls to ``NSInvocation`` methods under ARC that don't have proper
 argument object lifetimes. When passing Objective-C objects as parameters
 to the ``NSInvocation`` methods ``getArgument:atIndex:`` and
 ``getReturnValue:``, the values are copied by value into the argument pointer,
-which leads to to incorrect releasing behavior if the object pointers are
+which leads to incorrect releasing behavior if the object pointers are
 not declared ``__unsafe_unretained``.
 
 For code:
 
 .. code-block:: objc
 
     id arg;
     [invocation getArgument:&arg atIndex:2];

clang-tools-extra/docs/clang-tidy/checks/openmp-exception-escape.rst

 .. title:: clang-tidy - openmp-exception-escape
 
 openmp-exception-escape
 =======================
 
 Analyzes OpenMP Structured Blocks and checks that no exception escapes
 out of the Structured Block it was thrown in.
 
 As per the OpenMP specification, a structured block is an executable statement,
 possibly compound, with a single entry at the top and a single exit at the
-bottom. Which means, ``throw`` may not be used to to 'exit' out of the
+bottom. Which means, ``throw`` may not be used to 'exit' out of the
 structured block. If an exception is not caught in the same structured block
-it was thrown in, the behaviour is undefined.
+it was thrown in, the behavior is undefined.
 
 FIXME: this check does not model SEH, ``setjmp``/``longjmp``.
 
 WARNING! This check may be expensive on large source files.
 
 Options
 -------
 
 .. option:: IgnoredExceptions
 
    Comma-separated list containing type names which are not counted as thrown
    exceptions in the check. Default value is an empty string.

clang-tools-extra/docs/clang-tidy/checks/openmp-use-default-none.rst

 data sharing attribute, thus increasing readability and possibly making errors
 easier to spot.
 
 Example
 -------
 
 .. code-block:: c++
 
-  // ``for`` directive can not have ``default`` clause, no diagnostics.
+  // ``for`` directive cannot have ``default`` clause, no diagnostics.
   void n0(const int a) {
   #pragma omp for
     for (int b = 0; b < a; b++)
       ;
   }
 
   // ``parallel`` directive.
 

clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-algorithm.rst

 .. title:: clang-tidy - performance-inefficient-algorithm
 
 performance-inefficient-algorithm
 =================================
 
 
 Warns on inefficient use of STL algorithms on associative containers.
 
-Associative containers implements some of the algorithms as methods which
+Associative containers implement some of the algorithms as methods which
 should be preferred to the algorithms in the algorithm header. The methods
 can take advantage of the order of the elements.
 
 .. code-block:: c++
 
   std::set<int> s;
   auto it = std::find(s.begin(), s.end(), 43);
 

clang-tools-extra/docs/clang-tidy/checks/readability-const-return-type.rst

 .. title:: clang-tidy - readability-const-return-type
 
 readability-const-return-type
 =============================
 
 Checks for functions with a ``const``-qualified return type and recommends
 removal of the ``const`` keyword. Such use of `const` is usually superfluous,
-and can prevent valuable compiler optimizations.  Does not (yet) fix trailing
+and can prevent valuable compiler optimizations. Does not (yet) fix trailing
 return types.
 
 Examples:
 
 .. code-block:: c++
 
   const int foo();
   const Clazz foo();

clang-tools-extra/docs/clang-tidy/checks/readability-data-pointer.rst

 .. title:: clang-tidy - readability-data-pointer
 
 readability-data-pointer
 ========================
 
 Finds cases where code could use ``data()`` rather than the address of the
-element at index 0 in a container.  This pattern is commonly used to materialize
-a pointer to the backing data of a container.  ``std::vector`` and
+element at index 0 in a container. This pattern is commonly used to materialize
+a pointer to the backing data of a container. ``std::vector`` and
 ``std::string`` provide a ``data()`` accessor to retrieve the data pointer which
 should be preferred.
 
 This also ensures that in the case that the container is empty, the data pointer
 access does not perform an errant memory access.

clang-tools-extra/docs/clang-tidy/checks/readability-else-after-return.rst

.. option:: WarnOnUnfixable
    would have an extended lifetime if the ``else`` branch was removed.
    Default value is `true`.
 
 .. option:: WarnOnConditionVariables
 
    When `true`, the check will attempt to refactor a variable defined inside
    the condition of the ``if`` statement that is used in the ``else`` branch
    defining them just before the ``if`` statement. This can only be done if 
-   the ``if`` statement is the last statement in its parents scope.
+   the ``if`` statement is the last statement in its parent's scope.
    Default value is `true`.
 
 
 LLVM alias
 ----------
 
 There is an alias of this check called llvm-else-after-return.
 In that version the options :option:`WarnOnUnfixable` and 
 :option:`WarnOnConditionVariables` are both set to `false` by default.
 
 This check helps to enforce this `LLVM Coding Standards recommendation
 <https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return>`_.

clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst

 * sequences of binary logical operators:
 
    - ``boolean1 || boolean2``
    - ``boolean1 && boolean2``
 
 Nesting level
 ^^^^^^^^^^^^^
 
-While by itself the nesting level not change the function's Cognitive Complexity
-metric, it is tracked, and is used by the next, third building block.
+While by itself the nesting level does not change the function's Cognitive
+Complexity metric, it is tracked, and is used by the next, third building block.
 The following structures increase the nesting level (by `1`):
 
 * Conditional operators:
 
    - ``if()``
    - ``else if()``
    - ``else``
    - ``cond ? true : false``

clang-tools-extra/docs/clang-tidy/checks/readability-identifier-length.rst

.. code-block:: c++
       // This warns that 'e' is too short.
       catch (const std::exception& x) {
           // ...
       }
 
 .. option:: IgnoredExceptionVariableNames
 
     Specifies a regular expression for exception variable names that are to
-    be ignored.  The default value is `^[e]$` mainly for historical reasons.
+    be ignored. The default value is `^[e]$` mainly for historical reasons.
 
     .. code-block:: c++
 
       try {
           // ...
       }
       // This does not warn by default, for historical reasons.
       catch (const std::exception& e) {
           // ...
       }

clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst

 
 The naming of virtual methods is reported where they occur in the base class,
 but not where they are overridden, as it can't be fixed locally there.
 This also applies for pseudo-override patterns like CRTP.
 
 Options
 -------
 
-The following options are describe below:
+The following options are described below:
 
  - :option:`AbstractClassCase`, :option:`AbstractClassPrefix`, :option:`AbstractClassSuffix`, :option:`AbstractClassIgnoredRegexp`, :option:`AbstractClassHungarianPrefix`
  - :option:`AggressiveDependentMemberLookup`
  - :option:`ClassCase`, :option:`ClassPrefix`, :option:`ClassSuffix`, :option:`ClassIgnoredRegexp`, :option:`ClassHungarianPrefix`
  - :option:`ClassConstantCase`, :option:`ClassConstantPrefix`, :option:`ClassConstantSuffix`, :option:`ClassConstantIgnoredRegexp`, :option:`ClassConstantHungarianPrefix`
  - :option:`ClassMemberCase`, :option:`ClassMemberPrefix`, :option:`ClassMemberSuffix`, :option:`ClassMemberIgnoredRegexp`, :option:`ClassMemberHungarianPrefix`
  - :option:`ClassMethodCase`, :option:`ClassMethodPrefix`, :option:`ClassMethodSuffix`, :option:`ClassMethodIgnoredRegexp`
  - :option:`ConstantCase`, :option:`ConstantPrefix`, :option:`ConstantSuffix`, :option:`ConstantIgnoredRegexp`, :option:`ConstantHungarianPrefix`

clang-tools-extra/docs/clang-tidy/checks/readability-magic-numbers.rst

 .. title:: clang-tidy - readability-magic-numbers
 
 readability-magic-numbers
 =========================
 
 Detects magic numbers, integer or floating point literals that are embedded in
 code and not introduced via constants or symbols.
 
 Many coding guidelines advise replacing the magic values with symbolic
 constants to improve readability. Here are a few references:
 
-   * `Rule ES.45: Avoid “magic constants”; use symbolic constants in C++ Core Guidelines <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-magic>`_
+   * `Rule ES.45: Avoid "magic constants"; use symbolic constants in C++ Core Guidelines <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-magic>`_
    * `Rule 5.1.1 Use symbolic names instead of literal values in code in High Integrity C++ <http://www.codingstandard.com/rule/5-1-1-use-symbolic-names-instead-of-literal-values-in-code/>`_
    * Item 17 in "C++ Coding Standards: 101 Rules, Guidelines and Best
      Practices" by Herb Sutter and Andrei Alexandrescu
    * Chapter 17 in "Clean Code - A handbook of agile software craftsmanship."
      by Robert C. Martin
    * Rule 20701 in "TRAIN REAL TIME DATA PROTOCOL Coding Rules" by Armin-Hagen
      Weiss, Bombardier
    * http://wiki.c2.com/?MagicNumber
 

clang-tools-extra/docs/clang-tidy/checks/readability-qualified-auto.rst

.. option:: AddConstToQualified
    Default value is `true`.
 
 .. code-block:: c++
 
    auto Foo1 = cast<const int *>(Bar1);
    auto *Foo2 = cast<const int *>(Bar2);
    auto &Foo3 = cast<const int &>(Bar3);
 
-If AddConstToQualified is set to `false`,  it will be transformed into:
+If AddConstToQualified is set to `false`, it will be transformed into:
 
 .. code-block:: c++
 
    const auto *Foo1 = cast<const int *>(Bar1);
    auto *Foo2 = cast<const int *>(Bar2);
    auto &Foo3 = cast<const int &>(Bar3);
 
 Otherwise it will be transformed into:
 
 .. code-block:: c++
 
    const auto *Foo1 = cast<const int *>(Bar1);
    const auto *Foo2 = cast<const int *>(Bar2);
    const auto &Foo3 = cast<const int &>(Bar3);
 
 Note in the LLVM alias, the default value is `false`.

clang-tools-extra/docs/clang-tidy/checks/readability-redundant-declaration.rst

.. code-block:: c++
   extern int X;
 
 becomes
 
 .. code-block:: c++
 
   extern int X;
 
-Such redundant declarations can be removed without changing program behaviour.
+Such redundant declarations can be removed without changing program behavior.
 They can for instance be unintentional left overs from previous refactorings
 when code has been moved around. Having redundant declarations could in worst
 case mean that there are typos in the code that cause bugs.
 
 Normally the code can be automatically fixed, :program:`clang-tidy` can remove
 the second declaration. However there are 2 cases when you need to fix the code
 manually:
 

clang-tools-extra/docs/clang-tidy/checks/readability-string-compare.rst

.. code-block:: c++
   // use str1 != str2 instead.
   if (0 != str1.compare(str2)) {
   }
 
   // Use str1 == "foo" instead.
   if (str1.compare("foo") == 0) {
   }
 
-The above code examples shows the list of if-statements that this check will
+The above code examples show the list of if-statements that this check will
 give a warning for. All of them uses ``compare`` to check if equality or 
 inequality of two strings instead of using the correct operators.

clang-tools-extra/docs/clang-tidy/checks/readability-suspicious-call-argument.rst

 regards to `100`\%.
 For example, given ``something`` and ``anything``, the distance is `4` edits,
 and the similarity percentage is `100`\% `- 4 / 9 = 55.55...`\%.
 
 This heuristic can be configured with :ref:`bounds<opt_Bounds>`.
 The default bounds are: below `50`\% dissimilar and above `66`\% similar.
 This heuristic is case-sensitive.
 
-Jaro–Winkler distance (as `JaroWinkler`)
+Jaro-Winkler distance (as `JaroWinkler`)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The `Jaro–Winkler distance <http://en.wikipedia.org/wiki/Jaro–Winkler_distance>`_
+The `Jaro-Winkler distance <http://en.wikipedia.org/wiki/Jaro–Winkler_distance>`_
 is an edit distance like the Levenshtein distance.
 It is calculated from the amount of common characters that are sufficiently
 close to each other in position, and to-be-changed characters.
 The original definition of Jaro has been extended by Winkler to weigh prefix
 similarities more.
 The similarity percentage is expressed as an average of the common and
 non-common characters against the length of both strings.
 
 This heuristic can be configured with :ref:`bounds<opt_Bounds>`.
 The default bounds are: below `75`\% dissimilar and above `85`\% similar.
 This heuristic is case-insensitive.
 
-Sørensen–Dice coefficient (as `Dice`)
+Sørensen-Dice coefficient (as `Dice`)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The `Sørensen–Dice coefficient <http://en.wikipedia.org/wiki/Sørensen–Dice_coefficient>`_
+The `Sørensen-Dice coefficient <http://en.wikipedia.org/wiki/Sørensen–Dice_coefficient>`_
 was originally defined to measure the similarity of two sets.
 Formally, the coefficient is calculated by dividing `2 * #(intersection)` with
 `#(set1) + #(set2)`, where `#()` is the cardinality function of sets.
 This metric is applied to strings by creating bigrams (substring sequences of
 length 2) of the two strings and using the set of bigrams for the two strings
 as the two sets.
 
 This heuristic can be configured with :ref:`bounds<opt_Bounds>`.

clang-tools-extra/docs/clang-tidy/index.rst

 ``readability-``       Checks that target readability-related issues that don't
                        relate to any particular coding style.
 ``zircon-``            Checks related to Zircon kernel coding conventions.
 ====================== =========================================================
 
 Clang diagnostics are treated in a similar way as check diagnostics. Clang
 diagnostics are displayed by :program:`clang-tidy` and can be filtered out using
 ``-checks=`` option. However, the ``-checks=`` option does not affect
-compilation arguments, so it can not turn on Clang warnings which are not
+compilation arguments, so it cannot turn on Clang warnings which are not
 already turned on in build configuration. The ``-warnings-as-errors=`` option
 upgrades any warnings emitted under the ``-checks=`` flag to errors (but it
 does not enable any checks itself).
 
 Clang diagnostics have check names starting with ``clang-diagnostic-``.
 Diagnostics which have a corresponding warning option, are named
 ``clang-diagnostic-<warning-option>``, e.g. Clang warning controlled by
 ``-Wliteral-conversion`` will be reported with check name
The effective configuration can be inspected using -dump-config:
       ...
 
 .. _clang-tidy-nolint:
 
 Suppressing Undesired Diagnostics
 =================================
 
 :program:`clang-tidy` diagnostics are intended to call out code that does not
-adhere to a coding standard, or is otherwise problematic in some way.  However,
+adhere to a coding standard, or is otherwise problematic in some way. However,
 if the code is known to be correct, it may be useful to silence the warning.
 Some clang-tidy checks provide a check-specific way to silence the diagnostics,
-e.g.  `bugprone-use-after-move <checks/bugprone-use-after-move.html>`_ can be
+e.g. `bugprone-use-after-move <checks/bugprone-use-after-move.html>`_ can be
 silenced by re-initializing the variable after it has been moved out,
 `bugprone-string-integer-assignment
 <checks/bugprone-string-integer-assignment.html>`_ can be suppressed by
 explicitly casting the integer to ``char``,
 `readability-implicit-bool-conversion
 <checks/readability-implicit-bool-conversion.html>`_ can also be suppressed by
 using explicit casts, etc.