Re: Forcing Bison's yacc.c to report more expected tokens on syntax error

I agree with Adrian — it would be nicer, in my opinion, to allow users to handle syntax errors directly, rather than always going through the bison code which formats syntax errors in a fixed way.

This seems like it might be not too hard to do: replace the code starting with

    char const* yyformat = YY_NULLPTR;
    switch (yycount)
      {
#define YYCASE_(N, S)                         \
        case N:                               \
          yyformat = S;                       \
        break
…
	return yyres;

in yysyntax_error_ with a call like

    my_yysyntax_error(yyarg, yycount);

where “my_yysyntax_error” is a user-defined function which does the work of handling syntax error reporting.

In C++, we could be fancier: have two functions, one for a “pure” syntax error:

    void my_yysyntax_error();

and one for syntax errors involving unexpected tokens:

     void my_yysyntax_error(std::string unexpected_token, std::vector<std::string> expected_tokens);

The call would be something like this:

    if (yycount == 0) {
      my_yysyntax_error();
    } else {
      my_yysyntax_error(yyarg[0], std::vector<std::string>{yyarg + 1, yyarg + yycount});
    }

Derek

> On Feb 6, 2019, at 11:23 AM, Adrian Vogelsgesang <[email protected]> wrote:
> 
> Hi Kevin, hi Akim,
> 
> I can imagine cases where having a longer list of expected tokens might be useful.
> However, I wouldn’t like to have them in a string stitched together by bison, but instead I would like to have access to them in a std::vector<TokenId> or something similar.
> That way, I could do some post-processing of the expected token list (e.g., expand the “variable_name” token to all variables which are currently in scope).
> The result could then be integrated with, e.g., a dropdown list for autocompletion pretty nicely :)
> 
> Having programmatic access to the list of expected tokens would probably also solve Kevin’s request for reporting more than 5 tokens: he could just do it himself in his own code after getting the token list from Bison.
> 
> Cheers,
> Adrian
> 
> From: help-bison <[email protected]> on behalf of Akim Demaille <[email protected]>
> Date: Wednesday, 6 February 2019 at 10:43
> To: Kevin Villela <[email protected]>
> Cc: Bison Help <[email protected]>
> Subject: Re: Forcing Bison's yacc.c to report more expected tokens on syntax error
> 
> Hi Kevin,
> 
>> Le 6 févr. 2019 à 03:01, Kevin Villela <[email protected]> a écrit :
>> 
>> Hi all, I saw that the yacc.c skeleton only supports reporting a maximum or
>> 5 expected tokens. The page
>> <https://www.gnu.org/software/bison/manual/html_node/LAC.html<https://www.gnu.org/software/bison/manual/html_node/LAC.html>> on
>> Look-Ahead Correction states this is "because of internationalization
>> considerations". I was wondering if I would be able to contribute a
>> configuration option to increase this number arbitrarily, or even just up
>> to a higher number (e.g. 30) ?
> 
> The thing is that it's unclear that it actually helps to report all the possibilities when there are too many.
> _______________________________________________
> [email protected] https://lists.gnu.org/mailman/listinfo/help-bison<https://lists.gnu.org/mailman/listinfo/help-bison>
> _______________________________________________
> [email protected] https://lists.gnu.org/mailman/listinfo/help-bison

_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison