[C++ PATCH] Fix PR/9154 (a trunk regression)

Nathan Sidwell nathan@codesourcery.com
Mon Jun 23 12:13:00 GMT 2003


Giovanni Bajo wrote:
> Hello,
> 
> the following patch fixes PR/9154 by modifying the new parser to identify
> the ">>" token within a template argument list as a typo from the user for
> "> >", as it was done on the previous parser. This is done by loosely
> accepting CPP_RSHIFT as terminator of a (type) template argument, and later
> detecting it within cp_parser_template_id and emitting a proper diagnostic.
> 
> We could have done even better if there were a way to push artificial tokens
> within the lexer. In that case, we would have been able to push an
> additional CPP_GREATER when detecting a CPP_RSHIFT, thus allowing to
> continue parsing correctly.
> 
> This patch has been bootstrapped on i686-pc-cygwin (languages c, c++, java)
> and tested with a "make check-g++" with no new regressions. OK for mainline?
> 
> Giovanni Bajo

> *************** cp_parser_template_argument (cp_parser*
> *** 8220,8228 ****
>     cp_parser_parse_tentatively (parser);
>     argument = cp_parser_type_id (parser);
>     /* If the next token isn't a `,' or a `>', then this argument wasn't
> !      really finished.  */
>     if (cp_lexer_next_token_is_not (parser->lexer, CPP_COMMA)
> !       && cp_lexer_next_token_is_not (parser->lexer, CPP_GREATER))
>       cp_parser_error (parser, "expected template-argument");
>     /* If that worked, we're done.  */
>     if (cp_parser_parse_definitely (parser))
> --- 8231,8241 ----
>     cp_parser_parse_tentatively (parser);
>     argument = cp_parser_type_id (parser);
>     /* If the next token isn't a `,' or a `>', then this argument wasn't
> !      really finished. '>>' is probably a typo (the user meant '> >'), just
> !      pretend it is valid for now, it will be detected later. */
>     if (cp_lexer_next_token_is_not (parser->lexer, CPP_COMMA)
> !       && cp_lexer_next_token_is_not (parser->lexer, CPP_GREATER)
> !       && cp_lexer_next_token_is_not (parser->lexer, CPP_RSHIFT))
>       cp_parser_error (parser, "expected template-argument");

this is only safe if there are no type-names that are syntatically valid
lhs of >> operator. That is untrue, here is a counter example.

	struct X
	{
	  int operator >> (int);
	};
	template <int V> struct Foo {};
	Foo<X () >> 5> r;

X () is the typename for a function returning X taking no arguments
and the subexpression constructor of X.

Of course 'X () >> 5' is an invalid non-type template argument, but
that is a semantic check.

Does your patch DTRT with this?

nathan


-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk




More information about the Gcc-patches mailing list