2010/10/1 Jason Merrill <ja...@redhat.com>:
> It took me some searching, but yes, it does:
>
> "A type-specifier-seq shall not define a class or enumeration unless it
> appears in the type-id of an alias-declaration (7.1.3)."
>
> Normal declarations don't have a type-specifier-seq, they have a
> decl-specifier-seq.
No wonder I couldn't find it!
> I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
> instead of cp_parser_type_specifier_seq and then wait to complain about
> defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to me that it was
because it called cp_parser_commit_to_tentative_parse(), and if then I
wanted to roll-back the parsing of the range-for, I went badly. I had
to agree with Manuel that the tentative parsing is a bit messy...
But, I managed to solve this particual issue with the following patch
(no improvement in the error messages, however):
Index: gcc/cp/parser.c
===================================================================
--- gcc/cp/parser.c (revision 164871)
+++ gcc/cp/parser.c (working copy)
@@ -8644,21 +8644,13 @@ cp_parser_range_for (cp_parser *parser)
tree stmt, range_decl, range_expr;
cp_decl_specifier_seq type_specifiers;
cp_declarator *declarator;
- const char *saved_message;
tree attributes, pushed_scope;
cp_parser_parse_tentatively (parser);
- /* New types are not allowed in the type-specifier-seq for a
- range-based for loop. */
- saved_message = parser->type_definition_forbidden_message;
- parser->type_definition_forbidden_message
- = G_("types may not be defined in range-based for loops");
/* Parse the type-specifier-seq. */
cp_parser_type_specifier_seq (parser, /*is_declaration==*/true,
- /*is_trailing_return=*/false,
+ /*is_trailing_return=*/true,
&type_specifiers);
- /* Restore the saved message. */
- parser->type_definition_forbidden_message = saved_message;
/* If all is well, we might be looking at a declaration. */
if (cp_parser_error_occurred (parser))
{
Admittedly, this is not a "trailing_return_type", but AFAICT it has
exactly the same restrictions. Maybe renaming the parameter would be a
good idea.
Regards.
Rodrigo
