maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

[clang-tidy] Fix whitespace in docs. NFC 

Actually, just testing commits via monorepo ;)

llvm-svn: 351814
This commit is contained in:
Alexander Kornienko 2019-01-22 12:59:34 +00:00
parent 464bbe5812
commit 73eb326203
1 changed files with 14 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
clang-tools-extra/docs/clang-tidy/index.rst
View File

@ -260,21 +260,20 @@ An overview of all the command-line options:
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 not desired, the ``NOLINT`` or
// 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``/``NOLINTNEXTLINE`` is the following:
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