Re: FYI: yacc.c: YY_LOCATION_PRINT: Fix

[Akim Demaille]

>>> "Akim" == Akim Demaille <address@hidden> writes:

 > Le 28 sept. 04, à 00:12, Paul Eggert a écrit :

 >> "make check" now has 8 test failures, and I expect the recent set of
 >> patches are causing this.  Have you been running "make check"
 >> successfully?  If so, I can send more detailed output.
 >>
 > Yes, I know these failures.  Some are [...] due to the computation
 > of the default location [by Bison] when the rhs is empty.

One key question is: can the location of an empty reduction be
nonempty?

For instance, on this rule:

    foo: bar;

bison parse with an empty reduction before bar.  Before my patches
that broke the test suite, this empty reduction had an empty location.

Since in some cases, it is possible to consider the end of the
previous symbol, and the start of the coming lookahead, it is tempting
to consider that this is the location of the empty reduction.  In the
case above it would "accurately" consider that the empty reduction
spans one character (the white space).

But then...

But then, Paul's trick that considers that the location of a group of
reductions should ignore empty locations on a side no longer works
properly.

As a result, the location of the full rhs will include the space,
while before, it did not.  This is less elegant when referring to the
rhs.


I'm ambivalent on this change.  Does anybody have a clear cut answer?
Paul's trick is very nice, and we should probably include it in the
default handling of locations.

One possibility would be to add a flag to the locations,
"results_from_an_empty_reduction", but I'm reluctant to do that.