public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jason Merrill <jason@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-4584] c++: tweak parsing of invalid types Date: Wed, 20 Oct 2021 21:40:26 +0000 (GMT) [thread overview] Message-ID: <20211020214026.49A013857C60@sourceware.org> (raw) https://gcc.gnu.org/g:1c690164668bda556f308632eab4204f63a138d7 commit r12-4584-g1c690164668bda556f308632eab4204f63a138d7 Author: Jason Merrill <jason@redhat.com> Date: Mon Oct 18 16:12:15 2021 -0400 c++: tweak parsing of invalid types cp_parser_parse_and_diagnose_invalid_type_name is called during declaration parsing, so it should pass 'true' for the declarator_p argument. But that caused a diagnostic regression on template/pr84789.C due to undesired lookup in dependent scopes. To fix that, cp_parser_nested_name_specifier_opt needs to respect the value of check_dependency_p. This patch avoids a regression from Andrew Sharp's WIP patch for PR70417. It would make more sense to test only check_dependency_p, not declarator_p, but removing the declarator_p condition turns out to reveal complicated interactions of cp_parser_constructor_declarator_p and caching of nested-name-specifiers and template-ids that I've already spent too much time trying to sort out. gcc/cp/ChangeLog: * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Pass true for declarator_p. (cp_parser_nested_name_specifier_opt): Only look through TYPENAME_TYPE if check_dependency_p is false. Diff: --- gcc/cp/parser.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 9c7ed65f55c..49d951cfb19 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -3693,7 +3693,7 @@ cp_parser_parse_and_diagnose_invalid_type_name (cp_parser *parser) /*template_keyword_p=*/false, /*check_dependency_p=*/true, /*template_p=*/NULL, - /*declarator_p=*/false, + /*declarator_p=*/true, /*optional_p=*/false); /* If the next token is a (, this is a function with no explicit return type, i.e. constructor, destructor or conversion op. */ @@ -6605,6 +6605,8 @@ check_template_keyword_in_nested_name_spec (tree name) it unchanged if there is no nested-name-specifier. Returns the new scope iff there is a nested-name-specifier, or NULL_TREE otherwise. + If CHECK_DEPENDENCY_P is FALSE, names are looked up in dependent scopes. + If IS_DECLARATION is TRUE, the nested-name-specifier is known to be part of a declaration and/or decl-specifier. */ @@ -6645,9 +6647,10 @@ cp_parser_nested_name_specifier_opt (cp_parser *parser, /* Grab the nested-name-specifier and continue the loop. */ cp_parser_pre_parsed_nested_name_specifier (parser); /* If we originally encountered this nested-name-specifier - with IS_DECLARATION set to false, we will not have + with CHECK_DEPENDENCY_P set to true, we will not have resolved TYPENAME_TYPEs, so we must do so here. */ if (is_declaration + && !check_dependency_p && TREE_CODE (parser->scope) == TYPENAME_TYPE) { new_scope = resolve_typename_type (parser->scope, @@ -6729,6 +6732,7 @@ cp_parser_nested_name_specifier_opt (cp_parser *parser, a template. So, if we have a typename at this point, we make an effort to look through it. */ if (is_declaration + && !check_dependency_p && !typename_keyword_p && parser->scope && TREE_CODE (parser->scope) == TYPENAME_TYPE)
reply other threads:[~2021-10-20 21:40 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211020214026.49A013857C60@sourceware.org \ --to=jason@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).