[PATCH] c++: Add new warning options for C++ language mismatches

[Marek Polacek]

On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
> On 19/05/21 12:53 -0400, Marek Polacek wrote:
> > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches wrote:
> > > Jakub pointed out I'd forgotten the spaces before the opening parens
> > > for function calls. The attached patch should fix all those, with no
> > > other changes.
> > > 
> > > Tested x86_64-linux. OK for trunk?
> > 
> > Nice, this is cool.
> > 
> > > --- a/gcc/c-family/c.opt
> > > +++ b/gcc/c-family/c.opt
> > > @@ -431,6 +431,22 @@ Wc++20-compat
> > >  C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
> > >  Warn about C++ constructs whose meaning differs between ISO C++ 2017 and ISO C++ 2020.
> > > 
> > > +Wc++11-extensions
> > > +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++,Wall) Init(1)
> > > +Warn about C++11 constructs in code compiled with an older standard.
> > > +
> > > +Wc++14-extensions
> > > +C++ ObjC++ Var(warn_cxx14_extensions) Warning LangEnabledBy(C++ ObjC++,Wall) Init(1)
> > > +Warn about C++14 constructs in code compiled with an older standard.
> > > +
> > > +Wc++17-extensions
> > > +C++ ObjC++ Var(warn_cxx17_extensions) Warning LangEnabledBy(C++ ObjC++,Wall) Init(1)
> > > +Warn about C++17 constructs in code compiled with an older standard.
> > > +
> > > +Wc++20-extensions
> > > +C++ ObjC++ Var(warn_cxx20_extensions) Warning LangEnabledBy(C++ ObjC++,Wall) Init(1)
> > > +Warn about C++20 constructs in code compiled with an older standard.
> > > +
> > 
> > So these are enabled by -Wall but also turned on by default?  Let's choose one
> > and then drop either the Init(1) or the LangEnabledBy(C++ ObjC++,Wall) part?
> 
> Ah, good point. I mostly just cargo-cult what I see in that file (is
> the format documented somewhere?)

doc/options.texi I think.
 
> I think to preserve the current behaviour (using these constructs in
> an unsupported dialect warns by default) we want them to be Init(1)
> but not in -Wall. Or we could change the behaviour, and include them
> in -Wall and not Init(1), but then people who don't use -Wall (aka
> idiots and beginners) would not get the warnings.
> 
> Any preference?

Um.  Probably Init(1) aka status quo.  Frankly it sounds like a -pedantic thing
to me, but I guess let's not change that now.

Marek