[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted

[mark at codesourcery dot com]

------- 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