bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix %error-verbose for conflicts resolved by %nonassoc.


From: Akim Demaille
Subject: Re: Fix %error-verbose for conflicts resolved by %nonassoc.
Date: Wed, 26 Aug 2009 14:46:47 +0200


Le 25 août 09 à 09:10, Joel E. Denny a écrit :

Hi Joel,

Nice and deep work!

Verbose syntax error messages used to include error action tokens in the expected token list. There was a FIXME in conflicts.at about this. To
fix it, I pushed the following patches to master and similar ones to
branch-2.5. I feel this area is a bit too subtle to include this change
in branch-2.4.2.

I agree.

I'm not proud of propagating more preprocessor macros to yacc.c. Maybe
this is a good place for some more functions like the ones Akim has
discussed recently. Also, we could probably find better names than NINF.
For example, error_action or default_action.

Sounds good to me.

diff --git a/tests/conflicts.at b/tests/conflicts.at
index 98b7d41..f2f7861 100644
--- a/tests/conflicts.at
+++ b/tests/conflicts.at
@@ -99,20 +99,17 @@ AT_BISON_CHECK([-o input.c input.y])
AT_COMPILE([input])

AT_PARSER_CHECK([./input '0<0'])
-# FIXME: This is an actual bug, but a new one, in the sense that
-# no one has ever spotted it!  The messages are *wrong*: there should
-# be nothing there, it should be expected eof.
AT_PARSER_CHECK([./input '0<0<0'], [1], [],
-         [syntax error, unexpected '<', expecting '<' or '>'
+         [syntax error, unexpected '<'
])

AT_PARSER_CHECK([./input '0>0'])
AT_PARSER_CHECK([./input '0>0>0'], [1], [],
-         [syntax error, unexpected '>', expecting '<' or '>'
+         [syntax error, unexpected '>'
])

AT_PARSER_CHECK([./input '0<0>0'], [1], [],
-         [syntax error, unexpected '>', expecting '<' or '>'
+         [syntax error, unexpected '>'
])

I don't understand why it does not refer to eof, as was noted in the comment. I have not followed accurately everything you wrote about the NINF vs. 0 issue, but is it possible that the special case of end- of-file, which number is 0, be a reason about it? Maybe that would also explain my incorrect messages in the nearby thread about semantic error messages.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]