Re: C++: enum parsing speedups

[kaih at khms dot westfalen dot de (Kai Henningsen)]

nathan@codesourcery.com (Nathan Sidwell)  wrote on 04.09.04 in <41398F9C.2080608@codesourcery.com>:

> Zack Weinberg wrote:
> > 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?
> on the identifer is best. I'd guess that previously the error location
> was neither the identifier nor curly brace.

Well, that test was first proposed in

        http://gcc.gnu.org/ml/gcc-patches/1999-06/msg00108.html

and back then, you wrote:

> here's a patch to set an enum location to be the open `{' rather than
> some `random' point within the enum. (this makes the behaviour the same
> as gcc).

[...]

> old behaviour-
> enumtest.C:16: multiple definition of `enum thing'
> new behaviour-
> enumtest.C:14: multiple definition of `enum thing'
> enumtest.C:9: previous definition here
> gcc behaviour-
> enumtest.C:14: redeclaration of `enum thing'


MfG Kai