Re: FYI: bison-1.875 lets gcc bootstraps fail
| > From: Matthias Klose <doko@cs.tu-berlin.de>
| > 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 <akim@epita.fr>
|
| * 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 <eggert@twinsun.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.
Reply to: