| > From: Matthias Klose <[EMAIL PROTECTED]> | > 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 <[EMAIL PROTECTED]> | | * 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 PROTECTED]> | | * 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.
