[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: custom error messages
From: |
Akim Demaille |
Subject: |
Re: custom error messages |
Date: |
Sun, 5 Jan 2020 17:30:18 +0100 |
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!