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 address.
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. Repository: rC Clang https://reviews.llvm.org/D44883 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
