Details
- Reviewers
rsmith aaron.ballman
Diff Detail
Event Timeline
include/clang/Basic/DiagnosticIDs.h | ||
---|---|---|
39 | Is there any downside to just bumping it to, say, 4000 ? |
include/clang/Basic/DiagnosticIDs.h | ||
---|---|---|
39 | I think it is fine to bump it more.. |
Do we have evidence of false positive vs true positive rates for this catching actual problems in real world code? I realize that this is for GCC compatibility, but because it's default-off, I'm wondering where the utilities lies.
include/clang/Basic/DiagnosticIDs.h | ||
---|---|---|
39 | I think it should be done in a separate patch, and I agree that we should bump to 4000 for right now to give us some wiggle room. |
Some coding guidelines may require switch to have always default label. Even if devs know that default is not reachable, they can add default: abort(); or assert to increase safety (and warning will be silenced).
Yes, it not suitable to be enabled by default, but I still think it is good to have it.
We typically don't add new, default-off warnings because experience has shown that users don't enable them. The coding guidelines argument is somewhat persuasive, but I wonder whether this is better handled through clang-tidy checks rather than the compiler itself -- that's where we put other diagnostics that may not be suitable for the compiler. Have you thought about surfacing this functionality that way?
I honestly have to agree. I think it would be best as a clang-tidy check, because i can fully envision the exact opposite guideline, "avoid default so you get notified about every switch that needs to be updated".
I am not familiar with clang-tidy’s codebase and I personally prefer good compiler warnings than dependency on another tool (clang-tidy). I mean the cases when diagnostic check is easy to do in the compiler.
And in semaexpr we have all we need and it is simple to do it.
But if majority of reviewers disagree with compiler warning, I will close this revision.
While it is easy to do in the compiler frontend, I am not yet convinced it's really worth having there compared to clang-tidy. FWIW, I'd be happy seeing it in clang-tidy.
@rsmith maybe this should be a separate patch? I hit this limit in this patch.