X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/2c7f50be6247b4a03bdb27936ea6185cb6a7443c..29e20e22e0ecd5bf4c31c4ff32599ea5f404d136:/TODO diff --git a/TODO b/TODO index 404317f9..13c1f858 100644 --- a/TODO +++ b/TODO @@ -1,31 +1,11 @@ --*- outline -*- - * Short term -** Use syntax_error from the scanner? -This would provide a means to raise syntax error from function called -from the scanner. Actually, there is no good solution to report a -lexical error in general. Usually they are kept at the scanner level -only, ignoring the guilty token. But that might not be the best bet, -since we don't benefit from the syntactic error recovery. - -We still have the possibility to return an invalid token number, which -does the trick. But then the error message from the parser is poor -(something like "unexpected $undefined"). Since the scanner probably -already reported the error, we should directly enter error-recovery, -without reporting the error message (i.e., YYERROR's semantics). - -Back to lalr1.cc (whose name is now quite unfortunate, since it also -covers lr and ielr), if we support exceptions from yylex, should we -propose a lexical_error in addition to syntax_error? Should they have -a common root, say parse_error? Should syntax_error be renamed -syntactic_error for consistency with lexical_error? - ** Variable names. What should we name `variant' and `lex_symbol'? ** Use b4_symbol in all the skeleton -Then remove the older system, including the tables generated by -output.c +Move its definition in the more standard places and deploy it in other +skeletons. Then remove the older system, including the tables +generated by output.c ** Update the documentation on gnu.org @@ -58,17 +38,10 @@ as lr0.cc, why upper case? ** bench several bisons. Enhance bench.pl with %b to run different bisons. -** Use b4_symbol everywhere. -Move its definition in the more standard places and deploy it in other -skeletons. - * Various -** YYPRINT -glr.c inherits its symbol_print function from c.m4, which supports -YYPRINT. But to use YYPRINT yytoknum is needed, which not defined by -glr.c. - -Anyway, IMHO YYPRINT is obsolete and should be restricted to yacc.c. +** Warnings +Warnings about type tags that are used in printer and dtors, but not +for symbols? ** YYERRCODE Defined to 256, but not used, not documented. Probably the token @@ -118,50 +91,6 @@ so both 256 and 257 are "mysterious". ** YYFAIL It is seems to be *really* obsolete now, shall we remove it? -** YYBACKUP -There is no test about it, no examples in the doc, and I'm not sure -what it should look like. For instance what follows crashes. - - %error-verbose - %debug - %pure-parser - %code { - # include - # include - # include - - static void yyerror (const char *msg); - static int yylex (YYSTYPE *yylval); - } - %% - exp: - 'a' { printf ("a: %d\n", $1); } - | 'b' { YYBACKUP('a', 123); } - ; - %% - static int - yylex (YYSTYPE *yylval) - { - static char const input[] = "b"; - static size_t toknum; - assert (toknum < sizeof input); - *yylval = (toknum + 1) * 10; - return input[toknum++]; - } - - static void - yyerror (const char *msg) - { - fprintf (stderr, "%s\n", msg); - } - - int - main (void) - { - yydebug = !!getenv("YYDEBUG"); - return yyparse (); - } - ** yychar == yyempty_ The code in yyerrlab reads: @@ -198,7 +127,7 @@ some parts. * Header guards -From Franc,ois: should we keep the directory part in the CPP guard? +From François: should we keep the directory part in the CPP guard? * Yacc.c: CPP Macros @@ -208,8 +137,6 @@ They should not: it is not documented. But if they need to, let's find something clean (not like YYLSP_NEEDED...). -* Installation - * Documentation Before releasing, make sure the documentation ("Understanding your parser") refers to the current `output' format. @@ -447,6 +374,12 @@ Here's a proposal for how a new implementation might look: http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html + +Local Variables: +mode: outline +coding: utf-8 +End: + ----- Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.