Re: FYI: bison-1.875 lets gcc bootstraps fail
| > From: Matthias Klose <email@example.com>
| > Date: Fri, 10 Jan 2003 08:56:07 +0100
| > objc-parse.y: conflicts: 31 shift/reduce, 1 reduce/reduce
| > objc-parse.y: expected 0 reduce/reduce conflicts
| Thanks for the bug report. This failure is due to two recent changes
| to Bison. The first one appeared in Bison test version 1.30b:
| 2001-11-12 Akim Demaille <firstname.lastname@example.org>
| * src/conflicts.c (conflicts_print): Check %expect and make
| its violation an error.
| and the 2nd one first appeared in Bison test version 1.75f:
| 2002-12-26 Paul Eggert <email@example.com>
| * src/conflicts.c (conflicts_print): If the user specifies
| "%expect N", report an error if there are any reduce/reduce
| conflicts. This is what the manual says should happen.
| This fixes Debian bug 130890, reported by Anthony DeRobertis.
| In the interests of backward compatibility I am inclined to alter the
| Bison exit status to be what it was before Bison test version 1.30b.
| If we want %expect-count violations to cause Bison to exit, perhaps we
| can introduce a new feature (--pedantic-errors or %pedantic-errors,
| say?) to do that, after Bison 2.0 comes out. So I propose the
| following Bison patch for now. However I haven't installed it yet.
We need "%expect 1, 2", since for instance in GLR/BT you are "allowed"
to have rr conflicts.
But in the present case, in the future, we need no additional flag or
feature, we simply need the warning to turn into a hard error. Bison
is wrong, it needs to give some delay to the users, but once the delay
passed, it should go back to where it should always have been.