Hi,
On 08/11/2014 08:22 PM, Jason Merrill wrote:
OK with a comment explaining how we can get there.
Thanks. I'm going to apply the below, then. I suppose the simple
parser->scope clean up (
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01000.html) is also Ok, I
would rather commit both together.
Maybe more important, do you think my cp_parser_init_declarator change
is worth trying in mainline? If it doesn't give problems outside the
testsuites too nobody will regret those "invalid type in declaration" ;)
Thanks,
Paolo.
//////////////////////
2014-08-12 Paolo Carlini <paolo.carl...@oracle.com>
* parser.c (cp_parser_elaborated_type_specifier): Handle
specially cp_parser_template_id returning a BASELINK.
Index: parser.c
===================================================================
--- parser.c (revision 213837)
+++ parser.c (working copy)
@@ -15194,6 +15188,17 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
identifier. */
if (!template_p && !cp_parser_parse_definitely (parser))
;
+ /* We can get here when cp_parser_template_id, called by
+ cp_parser_class_name with tag_type == none_type, succeeds
+ and caches a BASELINK. Then, when called again here,
+ instead of failing and returning an error_mark_node
+ returns it (see template/typename17.C in C++11).
+ ??? Could we diagnose this earlier? */
+ else if (tag_type == typename_type && BASELINK_P (decl))
+ {
+ cp_parser_diagnose_invalid_type_name (parser, decl, token->location);
+ type = error_mark_node;
+ }
/* If DECL is a TEMPLATE_ID_EXPR, and the `typename' keyword is
in effect, then we must assume that, upon instantiation, the
template will correspond to a class. */
