[PATCH] D58154: Add support for -fpermissive.

rsmith abandoned this revision. rsmith added a comment. In D58154#1420565 , @aaron.ballman wrote: > If we go with a different name for the flag, then the user has to update > their build scripts to get code to compile with Clang, which means it >

[PATCH] D58154: Add support for -fpermissive.

aaron.ballman added a comment. In D58154#1420344 , @rsmith wrote: > I don't have particularly strong feelings one way or the other about > accepting `-fpermissive` at all. For GCC compatibility, it seems like a > moderately useful thing to support, but

[PATCH] D58154: Add support for -fpermissive.

rsmith added a comment. In D58154#1419956 , @jyknight wrote: > 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

[PATCH] D58154: Add support for -fpermissive.

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

[PATCH] D58154: Add support for -fpermissive.

aaron.ballman added a comment. In D58154#1418594 , @jyknight wrote: > The errors disabled by this feature are default-error warnings -- you can > already get the same effect by using -Wno-. Why is it bad to > additionally allow -fpermissive to disable

[PATCH] D58154: Add support for -fpermissive.

rsmith added a comment. In D58154#1418594 , @jyknight wrote: > The errors disabled by this feature are default-error warnings -- you can > already get the same effect by using -Wno-. Right; the `-fpermissive` mode added by this patch turns off strictly

[PATCH] D58154: Add support for -fpermissive.

jyknight added a comment. The errors disabled by this feature are default-error warnings -- you can already get the same effect by using -Wno-. 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

[PATCH] D58154: Add support for -fpermissive.

aaron.ballman added a comment. In D58154#1417474 , @rsmith wrote: > In D58154#1417363 , @aaron.ballman > wrote: > > > I'm not super keen on supporting -fpermissive -- what is the impetus for > > supporting this?

[PATCH] D58154: Add support for -fpermissive.

rsmith added a comment. In D58154#1417363 , @aaron.ballman wrote: > I'm not super keen on supporting -fpermissive -- what is the impetus for > supporting this? Is it just for GCC compatibility? Yes, exactly that -- this is to improve our drop-in

[PATCH] D58154: Add support for -fpermissive.

aaron.ballman added a comment. I'm not super keen on supporting -fpermissive -- what is the impetus for supporting this? Is it just for GCC compatibility? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58154/new/ https://reviews.llvm.org/D58154

[PATCH] D58154: Add support for -fpermissive.

jyknight added a comment. Hm -- in GCC, -fpermissive has nothing at all to do with -pedantic/-pedantic-errors, but I suppose it should be fine to do this way. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58154/new/ https://reviews.llvm.org/D58154

[PATCH] D58154: Add support for -fpermissive.

rsmith created this revision. rsmith added a reviewer: jyknight. Herald added a subscriber: jdoerfert. Herald added a project: clang. The intent is to provide similar functionality to GCC's -fpermissive. For Clang's approach to diagnostics, this means that we remap all extension diagnostics to no