[clang-tools-extra] r351814 - [clang-tidy] Fix whitespace in docs. NFC

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Jan 22 04:59:34 2019
New Revision: 351814

URL: http://llvm.org/viewvc/llvm-project?rev=351814&view=rev
Log:
[clang-tidy] Fix whitespace in docs. NFC

Actually, just testing commits via monorepo ;)

Modified:
    clang-tools-extra/trunk/docs/clang-tidy/index.rst

Modified: clang-tools-extra/trunk/docs/clang-tidy/index.rst
URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/index.rst?rev=351814&r1=351813&r2=351814&view=diff
==============================================================================
--- clang-tools-extra/trunk/docs/clang-tidy/index.rst (original)
+++ clang-tools-extra/trunk/docs/clang-tidy/index.rst Tue Jan 22 04:59:34 2019
@@ -260,21 +260,20 @@ An overview of all the command-line opti
 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, if it is known that the code is correct, the check-specific ways
-to silence the diagnostics could be used, if they are available (e.g.
-bugprone-use-after-move can be silenced by re-initializing the variable after it
-has been moved out, bugprone-string-integer-assignment can be suppressed by
-explicitly casting the integer to char, readability-implicit-bool-conversion can
-also be suppressed by using explicit casts, etc.). If they are not available or
-if changing the semantics of the code is not desired, the ``NOLINT`` or
-``NOLINTNEXTLINE`` comments can be used instead. For example:
+: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,
+if it is known that the code is correct, the check-specific ways to silence the
+diagnostics could be used, if they are available (e.g.  bugprone-use-after-move
+can be silenced by re-initializing the variable after it has been moved out,
+bugprone-string-integer-assignment can be suppressed by explicitly casting the
+integer to ``char``, readability-implicit-bool-conversion can also be suppressed
+by using explicit casts, etc.). If they are not available or if changing the
+semantics of the code is not desired, the ``NOLINT`` or ``NOLINTNEXTLINE``
+comments can be used instead. For example:
 
 .. code-block:: c++
 
-  class Foo
-  {
+  class Foo {
     // Silent all the diagnostics for the line
     Foo(int param); // NOLINT
 
@@ -283,7 +282,7 @@ if changing the semantics of the code is
 
     // Silent only the specified diagnostics for the next line
     // NOLINTNEXTLINE(google-explicit-constructor, google-runtime-int)
-    Foo(bool param); 
+    Foo(bool param);
   };
 
 The formal syntax of ``NOLINT``/``NOLINTNEXTLINE`` is the following:
@@ -307,8 +306,8 @@ The formal syntax of ``NOLINT``/``NOLINT
 
 Note that whitespaces between ``NOLINT``/``NOLINTNEXTLINE`` and the opening
 parenthesis are not allowed (in this case the comment will be treated just as
-``NOLINT``/``NOLINTNEXTLINE``), whereas in check names list (inside
-the parenthesis) whitespaces can be used and will be ignored.
+``NOLINT``/``NOLINTNEXTLINE``), whereas in check names list (inside the
+parenthesis) whitespaces can be used and will be ignored.
 
 .. _LibTooling: http://clang.llvm.org/docs/LibTooling.html
 .. _How To Setup Tooling For LLVM: http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html