Locations in bison itself are wrong

[Akim Demaille]

Hi Paul,

Your scheme for computing the locations in Bison itself is slightly
wrong, but touches a more general question.

The Bison problem is that you decide to use @0.end as a location for
@$ when there is no lhs.  This is fine *if* there is such thing as @0,
which is not the case when the very first nterm is empty, which is
precisely our case (declarations: /* Nothing */;).  So we get junk as
initial location, and it quite propagates itself.

The fix is easy: give a means to initialize @0, which is already what
lalr1.cc and glr.c do.  Something like:

@@ -1069,6 +1073,7 @@
   yyssp = yyss;
   yyvsp = yyvs;
   yylsp = yyls;
+  *yylsp = b4_location_initial;
   goto yysetstate;
 
 /*------------------------------------------------------------.

with a bit more m4_ifdef so that only people specifying it will
trigger the code (any K&R portability issue with struct assignments?).

An alternative would consist in using the location of the lookahead,
that, unfortunately, is not always available since Bison's parsers are
fairly lazy wrt calling yylex.  In particular at the beginning:

| ~/src/bison % tests/bison --trace=parse src/parse-gram.y
| Starting parse
| Entering state 0
| Reducing stack by rule 2 (line 169), -> declarations

First reduction.

| Stack now 0
| Entering state 2
| Reading a token: Next token is token "%debug" ( unknown token type)

First yylex invocation.

| Shifting token "%debug", Entering state 13
| Reducing stack by rule 6 (line 177), "%debug" -> declaration


So I'm not sure using the lookahead can really help the user in
commuting her @$.