On 18/06/2020 00:39, Akim Demaille wrote: > > >> Le 18 juin 2020 à 07:49, Daniele Nicolodi <dani...@grinta.net> a écrit : >> >> Hi Akim, >> >> On 17/06/2020 23:43, Akim Demaille wrote: >>> I think it's a mistake to try to use the semantic value in error messages. >> >> The goal would not be to use the semantic value in the error message, >> but to use additional context attached to the token by the lexer to >> decide how to report the error. > > Would you have an example of what you mean?
Sure, but it is rather contrived :-) I am working on a project that is based on Flex and Bison 3.4. The code goes through some contortions so that the lexer can report errors to the parser. I would like to make use of some of the features introduced in Bison 3.6 to try to avoid the most ugly ones. In the existing code, on error the lexer emits a LEX_ERROR token. This results in a grammar error that triggers error recovery (good) but also in an extra error emitted by Bison (bad). Right now the code checks the error messages in yyerror() and suppresses the unwanted error reporting if it contains the string "LEX_ERROR". I thought I could made use of the newly introduced yyreport_syntax_error() to simply check if the token that caused the error is LEX_ERROR and don't emit an error then. I haven't coded this, but I think this can be done. However, it would be nice if I could avoif having error reporting code in two places. I thought that one way to do it would be not to report the error in the lexer but to attach the error information as semantic value to the LEX_ERROR token, and do the error reporting from yyreport_syntax_error(). Simply returning YYerror from the lexer on error would solve half of the problem in a straight forward way. However, would like to avoid to have to change the token stream emitted by the lexer as it can be seen as API in this case. And it does not solve the (minor) issue of having error reorting code in two places. Did I say that the example is contrived? Thank you. Cheers, Dan