jyknight added a comment. Ah -- I now understand your concern, and managing user expectations appropriately does seem like a potential concern.
I did not look too closely before into what exactly GCC categorized as "permerror" (errors that can be disabled with -fpermissive) vs what Clang categorized as "ExtWarn,DefaultError" diagnostics. Looking into it a little more now, I think there may not actually be substantial overlap between the two right now. Many errors we have warning flags for are unconditional in GCC, and many that gcc allows disabling with -fpermissive are unconditional errors in clang. You gave examples of the latter already, and e.g. here's a bunch of bogus code which you can currently build with -Wno-everything in clang, but most of which cannot be disabled in gcc (and I believe most if not all of these flags are ExtWarn, so would be disabled by this proposed -fpermissive): https://godbolt.org/z/81NkJQ Given that, yeah, it may not actually make sense to call this behavior -fpermissive. I also can't really tell what the intent is behind classifying some diagnostics in Clang as ExtWarn,DefaultError and others Warning,DefaultError -- or if there even is any useful purpose there at all. I note with special-puzzlement the existence of both `ext_return_missing_expr` and `warn_return_missing_expr`. I guess my feeling now is that perhaps we should just eliminate that categorization as meaningless, and just make -Wno-error=everything work properly (for anyone who wants to not abort the compile on broken code, but for whatever reason also loves to see build-spam so doesn't want -Wno-everything). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58154/new/ https://reviews.llvm.org/D58154 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
