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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
