Re: Token value in custom error reporting

On 18/06/2020 00:39, Akim Demaille wrote: > > >> Le 18 juin 2020 à 07:49, Daniele Nicolodi 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

Re: Redefining the literal string associated to the YYerror symbol

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 a

Re: Token value in custom error reporting

Hi Akim, hi Daniele, actually, I would have a use case for accessing the semantic value for error message formatting, too... Probably less contrived ;) I am using bison for a SQL parser. One of the most common mistakes I see in queries written by beginners is that they get confused between stri

RE: Regarding building bison-3.4.2 on Windows

Thanks for your suggestion for newer version. If I build it on POSIX / Linux system , will that be compatible to windows ? My target is to build the source code provided for Windows. Do you provide installable for Windows ? Regards, Binay -Original Message- From: Akim Demaille Sent:

Re: Token value in custom error reporting

> On 18 Jun 2020, at 10:24, Daniele Nicolodi wrote: > > On 18/06/2020 00:39, Akim Demaille wrote: >> >> Would you have an example of what you mean? > … > 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

Re: Token value in custom error reporting

Daniele, > Le 18 juin 2020 à 10:24, Daniele Nicolodi a écrit : > >> 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 erro

Re: Token value in custom error reporting

Hi Adrian, > Le 18 juin 2020 à 11:26, Adrian Vogelsgesang a > écrit : > > Hi Akim, hi Daniele, > > It would probably help, if the error message would include something like >> Hint: Did you mean to refer to table "MyTable" instead of the string-literal >> 'MyTable'? >> If so, use double-quote

Re: Token value in custom error reporting

> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : > > In my C++ parser, the lexer has rule > . { return my_parser::token::token_error; } > > When it is triggers, I get the error: > :21.1: error: syntax error, unexpected token error > > It might be nicer to actually write out this tok

Re: Regarding building bison-3.4.2 on Windows

> Le 18 juin 2020 à 13:35, Singh, Binay a écrit : > > Thanks for your suggestion for newer version. > > If I build it on POSIX / Linux system , will that be compatible to windows ? I think that's the whole point of the POSIX subsystem. But I'm not a Windows user, I just don't know. > My t

Re: Token value in custom error reporting

Hi Akim, > That being said, this is clearly a nice-to-have and by no means necessary. > Also, I guess I would run into different issues, first (e.g., when encountering an error I would like to check "given the current state, would an identifier be valid". I don't think bison currentl

Re: Token value in custom error reporting

> On 18 Jun 2020, at 18:56, Akim Demaille wrote: > >> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : >> >> In my C++ parser, the lexer has rule >> . { return my_parser::token::token_error; } >> >> When it is triggers, I get the error: >> :21.1: error: syntax error, unexpected token e

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 10:35, Daniele Nicolodi 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 appe

Re: Token value in custom error reporting

> Le 18 juin 2020 à 19:11, Hans Åberg a écrit : > > >> On 18 Jun 2020, at 18:56, Akim Demaille wrote: >> >>> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : >>> >>> In my C++ parser, the lexer has rule >>> . { return my_parser::token::token_error; } >>> >>> When it is triggers, I

Re: Token value in custom error reporting

> On 18 Jun 2020, at 19:21, Akim Demaille wrote: > >> Le 18 juin 2020 à 19:11, Hans Åberg a écrit : >> >>> On 18 Jun 2020, at 18:56, Akim Demaille 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.htm

Re: Token value in custom error reporting

> Le 18 juin 2020 à 20:46, Hans Åberg 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

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 19:20, Akim Demaille a écrit : > >> 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"

Re: Redefining the literal string associated to the YYerror symbol

On 19/06/2020 00:13, Akim Demaille wrote: > Hi Daniele, > >> Le 18 juin 2020 à 19:20, Akim Demaille a écrit : >> >>> 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 th