srhines added a comment. > They'd already have had a chance to deal with their code when this was a > warning-default-error without "ShowInSystemHeaders"? (or, if the yhaven't > picked up a new compiler often enough, and they go from "a warning we didn't > care about" to "warning-default-error-with-ShowInSystemHeaders" - they're > still better off than if it'd gone straight to hard error, some chance to > cleanup while disabling the warning/error before picking up a compiler > version that makes it a hard error)
+1 for this. Having no intermediate step for developers to find/fix the warning in system headers (short of recompiling Clang with different settings) seems really rough for very downstream folks. One other thought I had was whether this should have a different way to suppress a "severe" warning (i.e. `-fno-really-I-know-I-should-fix-this-UB-hole` a la the now defunct flag for automatic initialization), because it is far too common for downstream developers of all sorts to encounter a warning once, see that they just don't care about that specific instance, and then slap on a `-Wno-foo` to their project forever. It almost seems like there should be a strongly-worded opt-out for these severe warning suppressions that might be behavior-changing (even if we later remove the ability for users to suppress them). I know that compiler developers don't like adding flags (let alone confusing ones for behaviors that we know should have been strict from the start), but it seems like there might be some tradeoff here that is worth it, considering how much other downstream cleanup might be needed for some compiler vendors. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150226/new/ https://reviews.llvm.org/D150226 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
