Re: error-tokens and locations?

[Paul Eggert]

Ian Badcoe <address@hidden> writes:

> Isn't the real problem that the framework shouldn't
> make calls like this in the first instance?

I'm not sure what you mean.  There needs to be a way to say that a
nonterminal is empty, i.e. that its location has empty extent.  If the
nonterminal is between two tokens A and B, we can say that it's empty
by saying that it starts just before B and ends just after A.  The
problem you're running into is what to do if the nonterminal comes
before the first token F in the program.  In that case, the code says
that it starts just before F and ends just after "??", where "??" is
currently some uninitialized data.  The initial action gives you a way
to initialize the "??".

> If you add the concept of empty locations, doesn't anybody who redefined
> YYLLOC_DEFAULT have to revisit their code?

Sure.

> neither the built-in definition of YYLLOC_DEFAULT nor the example
> given in the docs previously did any processing to accommodate the
> possibility of empty locations, so people's working code won't
> either.

It should be documented better, yes.

> I also wonder what the meaning of an empty location is, e.g. if it is
> passed all the way up to my error logging routine, what am I supposed
> to deduce about the error?

It depends on what your YYLLOC_DEFAULT does with such locations.  You
can see an example of one way to handle this problem in
src/parse-gram.y's lloc_default function.  Admittedly it's not pretty.

> if the error is not attributable to any part of the input, shouldn't
> it happen even without input?

No, because empty locations are still _somewhere_ -- they're typically
between two terminal symbols (though they can be before the first or
after the last terminal symbol), so you can still print useful
information about them.

> What part of my grammar was it which generated the calls to
> YYLLOC_DEFAULT with N = 0?  I certainly never intended to
> create any such actions and, if this is attributable to features
> of the grammar, then the simpler fix would seem to be to fix
> the grammar?

No, because Bison creates a top level grammar rule that it doesn't
tell you about.  Sorry.

> What does yacc do with regard to these ?

Traditional yacc doesn't have locations, so the problem doesn't occur.