chandlerc added a comment.
These kinds of improvements to warnings are awesome, but the way we are
deploying them presents serious challenges to adoption which I think we need to
I think significant new warning functionality should as a matter of course go
behind some warning group at least initially. I'd be fine with this being a
generic "-beta" group or some such, and I would be very happy with a clear
timeline for merging some of these flags away. But I think we need to give
users of Clang the ability to stage the deployment of a new compiler and the
cleanup of their code more effectively.
Secondly, there seems to be some interest in splitting off `OP=` combined
assignement-and-functionality warnings, but delays around getting consensus.
While we wait, users (including us) are forced to work around a problematic
warning. This is pretty disruptive. I think we need to be much more rapid it
moving this into a separate flag while it is under discussion because we don't
have anything like the above policy in place and well followed, we are
currently facing a really bad choice: disable the *entire* warning and
potentially regress our codebase, or commit really ugly hacks to work around a
bad warning. We can probably make it through this for this warning, but we need
to prioritize cleaning this up because it didn't go behind any kind of staging,
and going forward i strongly think we need a better way of staging these kinds
Note that this isn't novel -- the thread-safety warnings created exactly such a
staging arrangement to help address these kinds of rollout issues.
cfe-commits mailing list