aaron.ballman added a comment. In D58154#1418594 <https://reviews.llvm.org/D58154#1418594>, @jyknight wrote:
> The errors disabled by this feature are default-error warnings -- you can > already get the same effect by using -Wno-<lots-of-things>. Why is it bad to > additionally allow -fpermissive to disable them? (If we have any diagnostics > which are currently default-on-warnings which should not _ever_ be > disable-able, then maybe we should just fix those?) I believe -fpermissive controls more than just default-error warnings in GCC, and that's the kind of stuff I really don't want to support. For instance, there's no warning flag for this nonsense, but GCC accepts it under -fpermissive: https://godbolt.org/z/Q-Fl0i (If you think "but who does that?", this blog post shows up on the first page of a popular search engine when I search for fpermissive: http://blog.binchen.org/posts/always-turn-on-fpermissive-for-gcc-4-6.html). Another example of -fpermissive that I've seen in the wild is: https://godbolt.org/z/-44pK5 (which is warned on in C, but not controllable via a warning flag in C++). If we're going to claim support for -fpermissive as a GCC compatibility feature, then we'll get requests to support dialects like the above examples at some point as well and that's where my concern comes in -- I don't think we should ever support that kind of broken code. I'd be fine with what's proposed here under a different flag name though. 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
