Re: Token value in custom error reporting

[Hans Åberg]

> On 18 Jun 2020, at 19:21, Akim Demaille <akim@lrde.epita.fr> wrote:
> 
>> Le 18 juin 2020 à 19:11, Hans Åberg <haberg-1@telia.com> a écrit :
>> 
>>> On 18 Jun 2020, at 18:56, Akim Demaille <akim@lrde.epita.fr> wrote:
>>> 
>>> I have already explained what I don't think this is a good idea.
>>> 
>>> https://lists.gnu.org/r/help-bison/2020-06/msg00017.html
>>> 
>>> I also have explained that scanner errors should be handled
>>> by the scanner.  For instance, in the bistro, you can read:
>>> 
>>> int
>>> yylex (const char **line, YYSTYPE *yylval, YYLTYPE *yylloc)
>>> {
>>> int c;
>>> 
>>> [...]
>>> 
>>> switch (c)
>>>  {
>>> [...]
>>>    // Stray characters.
>>>  default:
>>>    yyerror (yylloc, "syntax error: invalid character: %c", c);
>>>    return TOK_YYerror;
>>>  }
>>> }
>>> 
>>> Cheers!
>> 
>> Is that not the case, which I responded to, where you get double error 
>> messages, both from the lexer and parser?
> 
> No, that's the whole point of YYerror.
> 
> In the news of 3.6:
> 
> *** Returning the error token
> 
>  When the scanner returns an invalid token or the undefined token
>  (YYUNDEF), the parser generates an error message and enters error
>  recovery.  Because of that error message, most scanners that find lexical
>  errors generate an error message, and then ignore the invalid input
>  without entering the error-recovery.
> 
>  The scanners may now return YYerror, the error token, to enter the
>  error-recovery mode without triggering an additional error message.  See
>  the bistromathic for an example.

Ah, I thought one should have something like that.

Otherwise, in your link above you suggest not using the semantic value in error 
messages, but when using locations, it contains the token delimitations. So 
there seems to be no advantage letting the lexer generating the error.