Adrian, > Le 4 janv. 2020 à 20:25, Adrian Vogelsgesang <[email protected]> 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!
