> On 19 Jun 2020, at 07:16, Akim Demaille wrote:
>
>> 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 ad
> 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
> 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
> 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
> 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
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
> 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
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
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
> 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
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
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
> 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 in the error message,
> but to use additional con
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.
Hi Daniele,
> Le 17 juin 2020 à 21:56, Daniele Nicolodi a écrit :
>
> Hello,
>
> error reporting has always been a pain point for me in the use of flex
> and bison, especially in coordinated error handling between the scanner
> and the grammar. I am very happy to see a lot of improvements in th
Hello,
error reporting has always been a pain point for me in the use of flex
and bison, especially in coordinated error handling between the scanner
and the grammar. I am very happy to see a lot of improvements in this
area in the 3.6 release!
Trying to use `%define parse.error custom` in a proj
Hello,
error reporting has always been a pain point for me in the use of flex
and bison, especially in coordinated error handling between the scanner
and the grammar. I am very happy to see a lot of improvements in this
area in the 3.6 release!
Trying to use `%define parse.error custom` in a proj
17 matches
Mail list logo
