aaron.ballman added inline comments.
================ Comment at: docs/clang-tidy/index.rst:280 + lint-command + lint-command lint-args + ---------------- xgsa wrote: > aaron.ballman wrote: > > This should have a subscript `opt` following `lint-args` to denote that the > > args are optional. I think you can achieve that with: > > ``` > > lint-args\ :sub:`opt` > > ``` > Sorry, I am not very familiar with Sphinx, but > ``` > \ :sub:`opt` > ``` > seems doesn't work inside `parsed-literal` block (I have searched through the > llvm docs and found a few similar places, which uses such construction in > `parsed-literal` block, and it is not rendered properly even on official web > site). > Here `parsed-literal` block is used to render a quote-like block with custom > formatting, so the whole grammar is shown as a single entity, and I cannot > achieve this with the other constructs. > To show that `lint-args` is optional I split this grammar rule into 2: > ``` > lint-command > lint-command lint-args > ``` > > Isn't it enough or are there any suggestions how to handle this? I think that's sufficient, thanks! ================ Comment at: docs/clang-tidy/index.rst:254-255 +While :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, there +are times when it is more appropriate to silence the diagnostic instead of +changing the semantics of the code. The preferable way of doing this is using ---------------- I would reword this somewhat now. I would put a period before ", there are times" and then move that whole "there are times" clause below. ================ Comment at: docs/clang-tidy/index.rst:256 +are times when it is more appropriate to silence the diagnostic instead of +changing the semantics of the code. The preferable way of doing this is using +the check-specific ways to mute diagnostics, if they are available (e.g. ---------------- s/preferable/preferred ================ Comment at: docs/clang-tidy/index.rst:257 +changing the semantics of the code. The preferable way of doing this is using +the 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 ---------------- s/mute/silence ================ Comment at: docs/clang-tidy/index.rst:261 +explicitly casting the integer to char, readability-implicit-bool-conversion +can also be suppressed by using explicit casts, etc.). Otherwise, +the ``NOLINT`` or ``NOLINTNEXTLINE`` comments can be used to silence ---------------- At the end of this sentence, I would put "However, there are times". e.g., However, there are times when it is more appropriate to silence the diagnostic instead of changing the semantics of the code. In these circumstances, the NOLINT or NOLINTNEXTLINE comments can be used to silence the diagnostic. https://reviews.llvm.org/D40671 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
