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: link
Be 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).