https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-01-16
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This happens during tentative parsing, so no errors are reported for decltype
not being followed by ( auto ) tokens and we segfault on trying to dereference
NULL open_paren to get open_paren->location.
The following patch avoids the ICE, on this testcase then reports:
--- gcc/cp/parser.c.jj 2020-01-16 12:15:47.211552009 +0100
+++ gcc/cp/parser.c 2020-01-16 17:41:39.322353708 +0100
@@ -18237,10 +18237,15 @@ cp_parser_placeholder_type_specifier (cp
placeholder = cp_lexer_consume_token (parser->lexer);
open_paren = cp_parser_require (parser, CPP_OPEN_PAREN,
RT_OPEN_PAREN);
- cp_parser_require_keyword (parser, RID_AUTO, RT_AUTO);
+ if (!open_paren)
+ return error_mark_node;
+ if (!cp_parser_require_keyword (parser, RID_AUTO, RT_AUTO))
+ return error_mark_node;
close_paren = cp_parser_require (parser, CPP_CLOSE_PAREN,
RT_CLOSE_PAREN,
open_paren->location);
+ if (!close_paren)
+ return error_mark_node;
}
}
pr92517.C:5:10: error: ‘C’ does not name a type
5 | requires C decltype<I>
| ^
Is that what we want, or do we want to emit an error even during tentative
parsing, or make the whole function deal with NULL open_paren and/or
close_paren and let the caller's do something? For open_paren it would be a
matter of open_paren ? open_paren->location : UNKNOWN_LOCATION, for close_paren
there is a single spot where we could use placeholder->location if close_paren
is NULL.
