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 
of improvements.

Note that this isn't novel -- the thread-safety warnings created exactly such a 
staging arrangement to help address these kinds of rollout issues.

  rC Clang

cfe-commits mailing list

Reply via email to