Re: Token value in custom error reporting

> On 19 Jun 2020, at 07:16, Akim Demaille <[email protected]> wrote:
> 
>> Le 18 juin 2020 à 20:46, Hans Åberg <[email protected]> a écrit :
>> 
>> 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.
> 
> It is still useful for the scanner to emit the error message, because the parser has no idea what is wrong.  Granted, it knows _where_ it's wrong, but not _why_:
> - invalid character?
> - not-closed string?
> - invalid escape sequence?
> - out-of-range literal number?
> - etc.
> 
> The scanner faces the error, *it* should say what's wrong.

Actually, I throw exceptions from the lexer, too. Like:
   throw mli::my_parser::syntax_error(yylloc, "Directive syntax error.”);

In addition, I have warnings, which Bison does not support. A snippet that use both errors and warnings:
        if (unused_variable != true)
          mli::my_parser::error(@x, "warning: " + ds);
        else
          throw syntax_error(@x, ds);

The error function checks if the string starts with “warning” and then does not write the “error: “ part.