------- Comment #6 from mark at codesourcery dot com 2008-11-11 20:09 -------
Subject: Re: [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof
expressions accepted
jason at redhat dot com wrote:
> This seems right to me. It's even what the comment at the top of the
> file says we do:
>
> Then, while we attempt to parse the construct, the parser queues
> up
> error messages, rather than issuing them immediately, and saves
> the
> tokens it consumes. If the construct is parsed successfully, the
>
> parser "commits", i.e., it issues any queued error messages and
>
> the tokens that were being preserved are permanently discarded.
>
> The simulate_error business only works for parse errors that indicate
> that this line of parsing won't work; it doesn't work for code that
> parses fine, but violates semantic rules and therefore needs an error.
I forgot that comment was still there. I think it's a lie, reflecting
an earlier implementation state. I found queuing up the messages to be
really difficult.
For a syntactically broken construct, we can just issue the error and
commit to the tentative parse at that point. I believe we do that in
some other places. It doesn't matter what top-level construct
(declaration or expression-statement) we might be looking at; something
like "__decltype( ;" is always invalid. Once you see "decltype (" , if
the parsing of the operand to decltype fails, we can commit to the
current tentative parse, issue the error, and move on.
However, I think the core bug here may be that the code you mention in
cp_parser_simple_declaration doesn't check to see if the parse has
already failed. Committing to the tentative parse is reasonable in that
situation if the parsing has succeeded thus far -- but if we've actually
hit a *parse* error, rather than a *semantic* error, we could safely
give up.
That will result in trying to parse the decltype again (now as an
expression statement), and we'll get an error that time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
