Re: Token value in custom error reporting

[Adrian Vogelsgesang]

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.com@gnu.org on behalf of 
daniele@grinta.net> wrote:

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