Re: custom error messages

[Akim Demaille]

Adrian,

> Le 4 janv. 2020 à 20:25, Adrian Vogelsgesang <address@hidden> a écrit :
> 
> Hi Akim
>  
> > Why not indeed. It will have to be implemented in all our skeletons
> > anyway, D included.
>  
> Great to hear! I wasn’t sure if you were planning to cover all skeletons
> or would focus on C

yacc.c is the most important one and the most painful one.  So let's
agree on this, the rest should easily follow.

 
> > My proposal (but returning an array of token numbers rather that token
> > names) would work for such a case, but it would be a bit wasteful: we
> > would first gather all the possible tokens in an array, and then remove
> > the useless ones.
> > 
> > Would that be ok with you?
>  
> That would certainly work for us. We are not optimizing for "syntax errors
> per second" anyway.

Which was what I believed :)

> My main ask here would be to expose the token numbers instead of the token
> names. One can always get the corresponding token name using a lookup in
> "yytname", so I would consider an interface which provides the token numbers
> as strictly superior.

I have updated my draft (see https://github.com/akimd/bison/pull/16).
The example looks like this currently:

> int
> yyreport_syntax_error (const yysyntax_error_context_t *ctx)
> {
>   enum { YYERROR_VERBOSE_ARGS_MAXIMUM = 10 };
>   /* Arguments of yyformat: reported tokens (one for the "unexpected",
>      one per "expected"). */
>   int arg[YYERROR_VERBOSE_ARGS_MAXIMUM];
>   int n = yysyntax_error_arguments (ctx, arg, sizeof arg / sizeof *arg);
>   if (n == -2)
>     return 2;
>   fprintf (stderr, "SYNTAX ERROR on token [%s]", yytname[arg[0]]);
>   if (1 < n)
>     {
>       fprintf (stderr, " (expected:");
>       for (int i = 1; i < n; ++i)
>         fprintf (stderr, " [%s]", yytname[arg[i]]);
>       fprintf (stderr, ")");
>     }
>   fprintf (stderr, "\n");
>   return 0;
> }

It uses the _internal_ token numbers.  It still uses yytname directly,
which I do not want to support/expose.  I will provide a function to do that
job (and take care of internationalization when enabled).

> One could tackle this particular use case also from a different angle:
> We could introduce the concept of "opaque" rules, i.e. rules which are not
> expanded when reporting syntax errors.
>  
> E.g., if I could define "unreserved_keyword" as
> > unreserved_keyword [opaqe]: ABORT_P | ABSOLUTE_P | <...>
> bison should then create the error message
> > expected: Identifier, unreserved_keyword
> instead of
> > expected: Identifier, <long list containing all unreserved keywords>

Too complex, and fitting just one special case.  With EDSLs, the
sheer concept of "keyword" is more complex than this.


Cheers!