[PATCH] D58154: Add support for -fpermissive.

[Aaron Ballman via Phabricator via cfe-commits]

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