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 string-literals
(single-quotes) and identifiers (double-quotes). I.e. they write the query
> SELECT * FROM 'MyTable'
instead of
> SELECT * FROM "MyTable"
This will be tokenized as "keyword<select> star keyword<from> string-literal".
The parser expects " keyword<select> star keyword<from> identifier" though.
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-quotes.
Now, I don't want to display this hint everytime when the user gave us a
string-literal, but the grammar expected an identifier.
I would only want to display this hint if there actually exists a table by this
name. And for that check, I would like to access the semantic value.
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 currently offers the API to do so)
Cheers,
Adrian
On 18/06/2020, 10:24, "help-bison on behalf of Daniele Nicolodi"
<help-bison-bounces+avogelsgesang=tableau....@gnu.org on behalf of
dani...@grinta.net> wrote:
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
