On 5/20/21 6:56 AM, Jonathan Wakely wrote:
On 19/05/21 16:05 -0400, Jason Merrill wrote:
On 5/19/21 3:55 PM, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely 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?

Jakub also pointed out we already have some similar diagnostics for
C++23, but I missed them as they say "only optional with" not "only
available with".

I'm testing the incremental change in the attached patch which also
adds -Wc++23-extensions, and I'll resend the full patch after that
finishes.

  if (omitted_parms_loc && lambda_specs.any_specifiers_p)
    {
-      pedwarn (omitted_parms_loc, 0,
+      pedwarn (omitted_parms_loc, OPT_Wc__23_extensions,

You probably want to change

 else if (cxx_dialect < cxx23)
   omitted_parms_loc = cp_lexer_peek_token (parser->lexer)->location;

To use warn_about_dialect_p.

Ah yes.

And just above that there's another pedwarn about a C++14 feature
being used:


     /* Default arguments shall not be specified in the
     parameter-declaration-clause of a lambda-declarator.  */
     if (cxx_dialect < cxx14)
    for (tree t = param_list; t; t = TREE_CHAIN (t))
      if (TREE_PURPOSE (t) && DECL_P (TREE_VALUE (t)))
        pedwarn (DECL_SOURCE_LOCATION (TREE_VALUE (t)), OPT_Wpedantic,
             "default argument specified for lambda parameter");


I didn't notice that one initially. That should also use
warn_about_dialect_p and OPT_Wc__14_extensions.

Indeed.

Should I change the message to say "init capture" rather than
"default argument"?

No, this is about e.g. [](int = 42){}

OK, this is a simpler version of the patch, with docs now, but without
the new warn_about_cxx_dialect_p function (which isn't needed) and
with no changes to any actual warning text (I'll do that separately,
if at all).

I also caught a few more pedwarn cases that I missed previously.

Tested powerpc64le-linux. OK for trunk?

This looks good to me, and the change overall simpler.  Just one
minor thing (sorry if that seems nit-picky): in the last sentence
in the documentation, does "this option" refer to the -Wc++11 form
or to the negative? (The latter is the one that's going to be
mentioned in the entry.)

If what the sentence is trying to say is that warnings for some C++
11 constructs are controlled only by -Wpedantic then I'd suggest to
rephrase it to make that part clearer (or drop it altogether since
it sounds like it describes a limitation/problem that we might want
to work toward fixing).

@@ -8154,6 +8156,41 @@ and ISO C++ 2017. This warning is enabled by @option{-Wall}.
 Warn about C++ constructs whose meaning differs between ISO C++ 2017
 and ISO C++ 2020.  This warning is enabled by @option{-Wall}.

+@item -Wno-c++11-extensions @r{(C++ and Objective-C++ only)}
+@opindex Wc++11-extensions
+@opindex Wno-c++11-extensions
+Do not warn about C++11 constructs in code being compiled using
+an older C++ standard.  Even without this option, some C++11 constructs
+will only be diagnosed if @option{-Wpedantic} is used.

Martin

Reply via email to