Re: Redefining the literal string associated to the YYerror symbol

[Akim Demaille]

Hi Daniele,

> Le 18 juin 2020 à 10:35, Daniele Nicolodi <daniele@grinta.net> a écrit :
> 
> On 18/06/2020 00:44, Akim Demaille wrote:
>> There is no way to rename it, and it wouldn't make sense as the error
>> token is never presented as an "expected token".  The error token never
>> shows to the (end) user.  It appears in the debug traces, but that's
>> for the developer.
> 
> What about YYEOF and YYUNDEF? Those appear in error messages.

Yes, they do.  However YYUNDEF should never be returned from the
scanner.  The scanner should catch the error, report the error
and tell the parser to enter error recovery.  That's YYerror.

YYUNDEF exists because it is "ok" to return chars, say '+', etc.
So when the parser receives a char, say 'x', it has to check if it
has support for it, and if not it maps it to YYUNDEF internally,
so that "it knows how to deal with it".

But to my eyes, this is truly a programmer error.  The scanner
should never return "non existing tokens".  So I won't pay much
attention on how YYUNDEF looks like in the error messages–it should
never be there.

YYEOF is a different beast, and you can change it.
https://www.gnu.org/software/bison/manual/html_node/Token-I18n.html



> However I have a ton of tests that expect the lexer to emit a
> "LEX_ERROR" token on error and I am considering to use YYerror special
> token to report errors instead. Thus the question if I can rename
> YYerror from "error" to "LEX_ERROR".
> 
> The fix is rather easy:
> 
> const char* token_name(int token)
> {
>    if (token == YYerror)
>        return "LEX_ERROR";
>    return yysymbol_name(YYTRANSLATE(token));
> }

It looks reasonable.


Cheers!