[PATCH] D40671: [clang-tidy] Support specific checks for NOLINT directive

[Anton via Phabricator via cfe-commits]

xgsa marked 2 inline comments as done.
xgsa added inline comments.


================
Comment at: docs/clang-tidy/index.rst:253
 
+Generally, there is no need to suppress :program:`clang-tidy` diagnostics. If
+there are false positives, either a bug should be reported or the code should be
----------------
alexfh wrote:
> aaron.ballman wrote:
> > I don't agree with that initial statement's use of "generally" -- checks that are chatty live in clang-tidy, as are checks for various coding standards (which commonly have a  deviation mechanism). Also, I don't think we should encourage users to unconditionally report false positives as bugs; many of the coding standard related checks provide true positives that are annoying and users may want to deviate in certain circumstances (like CERT's rule banning use of `rand()` or `system()`). I would reword this to:
> > ```
> > While clang-tidy diagnostics are intended to call out code that does not adhere to a coding standard, or is otherwise problematic in some way, there are times when it is more appropriate to silence the diagnostic instead of changing the semantics of the code. In such circumstances, the NOLINT or NOLINTNEXTLINE comments can be used to silence the diagnostic. For example:
> > ```
> > I would also describe the comment syntax more formally as (my markdown may be incorrect, you should ensure this renders sensibly), with surrounding prose:
> > ```
> > *lint-comment:*
> >   *lint-command* *lint-args~opt~*
> >   
> > *lint-args:*
> >   `(` *check-name-list* `)`
> > 
> > *check-name-list:*
> >   *check-name*
> >   *check-name-list* `,` *check-name*
> > 
> > *lint-command:*
> >   `NOLINT`
> >   `NOLINTNEXTLINE`
> > ```
> > Specific to the prose mentioned above, you should document where the feature is tolerant to whitespace (can there be a space between NOLINT and the parens, what about inside the parens, how about after or before commas, etc).
> One little request from me: the documentation should recommend using check-specific ways to mute diagnostics, if they are available (e.g. bugprone-use-after-move can be silenced by re-initializing the variable after it has been moved out, misc-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.). NOLINT(NEXTLINE)? should be treated as the last resort, when fixing the code is infeasible or impractical and there's no diagnostic-specific suppression mechanism available.
Thank you for the examples of the check-specific mute ways, I have looked for that, but haven't found the good ones.


https://reviews.llvm.org/D40671