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