[PATCH] D151187: [doc] Add casting style preference to coding standards

[Aaron Ballman via Phabricator via llvm-commits]

aaron.ballman added a comment.

In D151187#4366059 <https://reviews.llvm.org/D151187#4366059>, @mehdi_amini wrote:

>> We do have off-by-default warnings but those tend to mostly be: historical warnings we likely would never add today, pedantic warnings for extensions/future standards compatibility, or they're for extremely one-off situations (like serious performance concerns that aren't also correctness concerns). We have evident that off-by-default warnings basically do not get enabled often enough to warrant adding them to the tool. So getting LLVM warning free for this wouldn't actually move the needle all that much.
>
> We're off-topic, but is there a discussion/reference about this I can read?( this seems actually pretty unfortunate to me: clang-tidy is nice but hardly a replacement since it isn't really in the day-to-day developer flow).

Once upon a time, someone did some digging to see just how often the various off-by-default warnings were enabled across a significant corpus of code and found it was a very low percentage pretty much across the board. However, that was *years* ago at this point and I can't find the discussion in my archives.

However, as an example of some off-by-default warnings, we have `-Wzero-as-null-pointer-constant` as an off-by-default warning, and at first it looks like it's heavily used: https://sourcegraph.com/search?q=context:global+-Wzero-as-null-pointer-constant+-file:.*test.*&patternType=standard&sm=1&groupBy=repo but when you look more closely, you see that the vast majority of "uses" are trying to disable the warning if it's already enabled. We have `-Wshadow-field` off-by-default, same situation: https://sourcegraph.com/search?q=context:global+-Wshadow-field+-file:.*test.*&patternType=standard&sm=1&groupBy=repo

clang-tidy exists specifically because we wanted a tool people could integrate into their CI pipeline for more opinionated diagnostics. It's particularly good for enforcing coding standards because of how often those also make style choices. It can be used in the day-to-day workflow (for example, I know of at least one person who integrates it into VS Code through clangd to get IDE integration and then runs clang-tidy ahead of clang within their builds), but perhaps there are ways we can make it more ergonomic so that's easier.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151187/new/

https://reviews.llvm.org/D151187