[Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Adam Butcher]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Hi again,

The attached patch attempts to resolve bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709  Allowing
decltype(expr) to appear as the start of a nested-name-specifier.

However there is something wrong.  Although it parses fine, the
resulting tree seems to be treated as if it were dependent on a template
parameter.  An additional 'typename' prefix is required to get the
desired behaviour.

Although this seems to work for many scenarios, the resulting tree
seems to be treated as dependent (in the sense of dependent on a
template parameter) even when used outside of a template.  For
instance:

  struct X {};
  struct Y { typedef X Inner; enum { E = 7 }; };
  Y y;
  decltype(y)::Inner x;          // error: 'Inner' does not name a type
  typename decltype(y)::Inner x; // works fine
  int e = decltype(y)::E;        // works fine

I don't think decltype(y) should be deferred in any way, as it should
be known.  Something's obviously missing but I'm not sure what.

Any help appreciated.

Cheers
Adam

[-- Attachment #2: 0001-C-0x-Support-decltype-specifier-as-start-of-nested-n.patch --]
[-- Type: application/octet-stream, Size: 4014 bytes --]

From 70d0074a1da77d587979b0ba05f82f46d4196fd9 Mon Sep 17 00:00:00 2001
From: Adam Butcher <dev.lists@jessamine.co.uk>
Date: Thu, 20 Jan 2011 16:33:34 +0000
Subject: [PATCH] [C++0x] Support decltype-specifier as start of nested-name-specifier.

Although this seems to work for many scenarios, the resulting tree
seems to be treated as dependent (in the sense of dependent on a
template parameter) even when used outside of a template.  For
instance:

  struct X {};
  struct Y { typedef X Inner; enum { E = 7 }; };
  Y y;
  decltype(y)::Inner x;          // error: 'Inner' does not name a type
  typename decltype(y)::Inner x; // works fine
  int e = decltype(y)::E;        // works fine

I don't think decltype(y) should be deferred in any way, as it should
be known.  Something's obviously missing but I'm not sure what.
---
 gcc/cp/parser.c |   37 +++++++++++++++++++++++++++++--------
 1 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d67dd51..37b49d0 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -4477,6 +4477,7 @@ cp_parser_unqualified_id (cp_parser* parser,
    nested-name-specifier: [C++0x]
      type-name ::
      namespace-name ::
+     decltype-specifier ::
      nested-name-specifier identifier ::
      nested-name-specifier template [opt] simple-template-id ::
 
@@ -4551,6 +4552,9 @@ cp_parser_nested_name_specifier_opt (cp_parser *parser,
       /* A template-id can start a nested-name-specifier.  */
       else if (token->type == CPP_TEMPLATE_ID)
 	;
+      /* A decltype-specifier can start a nested-name-specifier.  */
+      else if (token->keyword == RID_DECLTYPE)
+	;
       else
 	{
 	  /* If the next token is not an identifier, then it is
@@ -4603,13 +4607,16 @@ cp_parser_nested_name_specifier_opt (cp_parser *parser,
 	parser->scope = resolve_typename_type (parser->scope,
 					       /*only_current_p=*/false);
       /* Parse the qualifying entity.  */
-      new_scope
-	= cp_parser_qualifying_entity (parser,
-                                       typename_keyword_p,
-                                       template_keyword_p,
-                                       check_dependency_p,
-                                       type_p,
-                                       is_declaration);
+      if (token->keyword == RID_DECLTYPE)
+	new_scope = cp_parser_decltype (parser);
+      else
+        new_scope
+	  = cp_parser_qualifying_entity (parser,
+                                         typename_keyword_p,
+                                         template_keyword_p,
+                                         check_dependency_p,
+                                         type_p,
+                                         is_declaration);
       /* Look for the `::' token.  */
       cp_parser_require (parser, CPP_SCOPE, RT_SCOPE);
 
@@ -12682,7 +12689,8 @@ cp_parser_simple_type_specifier (cp_parser* parser,
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
 
-  /* If we're looking at a keyword, things are easy.  */
+  /* If we're looking at a keyword, things are easy.  Except if it's
+     `decltype'. */
   switch (token->keyword)
     {
     case RID_CHAR:
@@ -12750,6 +12758,17 @@ cp_parser_simple_type_specifier (cp_parser* parser,
       break;
 
     case RID_DECLTYPE:
+      /* Decltype could start a nested-name-specifier. */
+      if (cp_parser_nested_name_specifier_opt (parser,
+					       /*typename_keyword_p=*/false,
+					       /*check_dependency_p=*/false,
+					       /*type_p=*/false,
+					       /*is_declaration=*/false)
+	  != NULL_TREE)
+	{
+	  goto check_user_defined;
+	}
+
       /* Parse the `decltype' type.  */
       type = cp_parser_decltype (parser);
 
@@ -12807,6 +12826,8 @@ cp_parser_simple_type_specifier (cp_parser* parser,
       return TYPE_NAME (type);
     }
 
+ check_user_defined:
+
   /* The type-specifier must be a user-defined type.  */
   if (!(flags & CP_PARSER_FLAGS_NO_USER_DEFINED_TYPES))
     {
-- 
1.7.2

Re: [Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Jason Merrill]

Now that we're in stage 1 again, I'd like to get your decltype changes 
integrated.  Sorry I didn't respond sooner.

On 01/20/2011 11:51 AM, Adam Butcher wrote:
> The attached patch attempts to resolve bug
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709  Allowing
> decltype(expr) to appear as the start of a nested-name-specifier.
>
> However there is something wrong.  Although it parses fine, the
> resulting tree seems to be treated as if it were dependent on a template
> parameter.  An additional 'typename' prefix is required to get the
> desired behaviour.
>
> Although this seems to work for many scenarios, the resulting tree
> seems to be treated as dependent (in the sense of dependent on a
> template parameter) even when used outside of a template.  For
> instance:
>
>    struct X {};
>    struct Y { typedef X Inner; enum { E = 7 }; };
>    Y y;
>    decltype(y)::Inner x;          // error: 'Inner' does not name a type

It's not that it's treated as dependent; the patch to 
cp_parser_simple_type parses the nested-name-specifier, then discards it 
and doesn't rewind the input stream, so the later call to 
cp_parser_nested_name_specifier doesn't see it and it's as though the 
"decltype(y)::" didn't exist.

I think you want to arrange to skip the lower calls to 
cp_parser_global_scope_opt and cp_parser_nested_name_specifier in this case.

Do you have tests for your decltype patches?

Jason

Re: [Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Adam Butcher]

On Fri, April 1, 2011 11:06 pm, Jason Merrill wrote:
> Now that we're in stage 1 again, I'd like to get your decltype changes
> integrated.  Sorry I didn't respond sooner.
>
No worries.  I'm guilty of not checking mails for months due to other
commitments so didn't see either of your responses (or the committed
fix) on this decltype stuff until now.

> On 01/20/2011 11:51 AM, Adam Butcher wrote:
>>
>> Although this seems to work for many scenarios, the resulting tree
>> seems to be treated as dependent (in the sense of dependent on a
>> template parameter) even when used outside of a template.  For
>> instance:
>>
>>    struct X {};
>>    struct Y { typedef X Inner; enum { E = 7 }; };
>>    Y y;
>>    decltype(y)::Inner x;          // error: 'Inner' does not name a
>> type
>
> It's not that it's treated as dependent; the patch to
> cp_parser_simple_type parses the nested-name-specifier, then discards it
> and doesn't rewind the input stream, so the later call to
> cp_parser_nested_name_specifier doesn't see it and it's as though the
> "decltype(y)::" didn't exist.
>
> I think you want to arrange to skip the lower calls to
> cp_parser_global_scope_opt and cp_parser_nested_name_specifier in this
> case.
>
Thanks for the explanation.  Seeing as you've fixed this proper now I'll
have a look at you changeset for info.  Cheers for picking this up.

> Do you have tests for your decltype patches?
>
I assume you no longer need these as you've made your own on 176513 right?

Adam

Re: [Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Jason Merrill]

On 07/21/2011 11:48 AM, Adam Butcher wrote:
> On Fri, April 1, 2011 11:06 pm, Jason Merrill wrote:
>> Now that we're in stage 1 again, I'd like to get your decltype changes
>> integrated.  Sorry I didn't respond sooner.
>>
> No worries.  I'm guilty of not checking mails for months due to other
> commitments so didn't see either of your responses (or the committed
> fix) on this decltype stuff until now.

I was beginning to think you were dead or something, glad to see that's 
not the case.  :)

>> Do you have tests for your decltype patches?
>>
> I assume you no longer need these as you've made your own on 176513 right?

Yes, though they aren't terribly exhaustive if you have ideas about 
other variations we ought to test...

Incidentally, the GNU copyright clerk told me that your copyright 
assignment isn't complete yet.

Jason

Re: [Patch] [C++0x] Support decltype-specifier as start of nested-name-specifier. (Bug 6709)

[Adam Butcher]

On Fri, July 22, 2011 10:23 pm, Jason Merrill wrote:
> On 07/21/2011 11:48 AM, Adam Butcher wrote:
>> No worries.  I'm guilty of not checking mails for months due to other
>> commitments so didn't see either of your responses (or the committed
>> fix) on this decltype stuff until now.
>
> I was beginning to think you were dead or something, glad to see that's
> not the case.  :)
>
:)

>>> Do you have tests for your decltype patches?
>>>
>> I assume you no longer need these as you've made your own on 176513
>> right?
>
> Yes, though they aren't terribly exhaustive if you have ideas about
> other variations we ought to test...
>
Just glanced over the changeset and looks like the tests are pretty much
equivalent to my own -- just spelt differently.  Just building 4.7 head
now.

> Incidentally, the GNU copyright clerk told me that your copyright
> assignment isn't complete yet.
>
That's odd.  I thought that was sorted ages ago around the time of the
old lambda branch fixes (pre 4.5) and the polymorphic lambda stuff.  I
definitely sent the paperwork off.  Who do I need to contact to sort
that out?  I do intend to recreate the polymorphic lambda stuff against
4.7 at some point when I get some breathing time.  The original patch no
longer fits and had some problems.