On 11/19/19 11:46 PM, Jakub Jelinek wrote:
Hi!

In lambdas, the only valid decl specifiers are mutable, constexpr or
consteval.  For various other simple specifiers it is fine to parse them
and reject afterwards if the parsing is simple consuming of a single token
and setting some flags, but as the testcase shows, especially allowing
type specifiers, including new type definitions in there can cause ICEs.
The following patch punts for the cases where the parsing isn't that simple,
which I think is concept, typedef (there we e.g. commit tentative parsing)
or the type specifiers.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok of trunk?

2019-11-19  Jakub Jelinek  <ja...@redhat.com>

        PR c++/90842
        * parser.c (cp_parser_decl_specifier_seq): For concept, typedef
        or type specifier with CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR
        don't try to parse them at all.

        * g++.dg/cpp1y/lambda-generic-90842.C: New test.
        * g++.dg/cpp0x/lambda/lambda-86550.C: Adjust expected diagnostics.

--- gcc/cp/parser.c.jj  2019-11-14 09:13:24.356104252 +0100
+++ gcc/cp/parser.c     2019-11-19 17:47:24.776014270 +0100
@@ -14094,6 +14094,12 @@ cp_parser_decl_specifier_seq (cp_parser*
          break;
case RID_CONCEPT:
+          if (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
+            {
+             found_decl_spec = false;
+             break;
+            }
+
            ds = ds_concept;
            cp_lexer_consume_token (parser->lexer);

It would seem better to break after consuming the token, so we just skip the extra processing and still give the same error.

@@ -14136,6 +14142,12 @@ cp_parser_decl_specifier_seq (cp_parser*
          /* decl-specifier:
               typedef  */
        case RID_TYPEDEF:
+          if (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
+            {
+             found_decl_spec = false;
+             break;
+            }
+
          ds = ds_typedef;
          /* Consume the token.  */
          cp_lexer_consume_token (parser->lexer);
@@ -14229,7 +14241,9 @@ cp_parser_decl_specifier_seq (cp_parser*
/* If we don't have a DECL_SPEC yet, then we must be looking at
         a type-specifier.  */
-      if (!found_decl_spec && !constructor_p)
+      if (!found_decl_spec
+         && !constructor_p
+         && (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR) == 0)

And instead of this, maybe set CP_PARSER_FLAGS_NO_TYPE_DEFINITIONS so we keep the same diagnostic for other type-specifiers?

Jason

Reply via email to