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