thakis added a comment. In https://reviews.llvm.org/D44883#1048751, @dblaikie wrote:
> Historically Clang's policy on warnings was, I think, much more > conservative than it seems to be today. There was a strong desire not to > implement off-by-default warnings, and to have warnings with an > exceptionally low false-positive rate - maybe the user-defined operator > detection was either assumed to, or demonstrated to, have a sufficiently > high false positive rate to not meet that high bar. This is still the case. For a new warning, you should evaluate some large open-source codebase and measure true positive and false positive rate and post the numbers here. > (as for the flag splitting - that was sometimes done if the new variant of > a flag had enough bug-finding power that an existing codebase using the > existing flag behavior would need significant cleanup - by having the new > functionality under another flag name, existing codebases upgrading to a > newer compiler wouldn't be forced to either do all that cleanup up-front or > disable the flag & risk regressions... ) 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
