Re: C++: enum parsing speedups

[Zack Weinberg <zack at codesourcery dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> We don't want do add more of those calls if we can help it; those 
> functions are on the fast path, and the c_l_s_s_p function is not free.  
> Just change the error markers in the test case, assuming the messages 
> come out somewhere sensible.  We've done that plenty in the past; 
> whether or not an error message shows up on the {enum,class}-specifier, 
> or the curly brace, is not a very big deal.

I'm fine with that - in fact I personally think it makes more sense
for the message to come out on the line with the identifier on it -
but the point of g++.other/enum2.C is very specifically to enforce
that the message comes out on the line with the curly brace.  I'm
cc:ing Nathan Sidwell as he added the test.  Nathan, do you still have
an opinion here?

It occurs to me that I could call c_l_s_s_p from
cp_parse_enum_specifier if we really do want the message on the curly
brace, so I needn't put it in the token consumption calls.

I wonder how hard it would be to get rid of c_l_s_s_p altogether. >>queue...

zw