gnulib: update

[bison.git] / TODO

diff --git a/TODO b/TODO
index 1c5d3585fa0410788a3ac5f2dba0caf17b6c0081..7a6734b8f2fca9efd8e47b827f77d727f18529f9 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,23 +1,64 @@
 * Short term
 * Short term

-** scan-code.l
-Avoid variables for format strings, as then GCC cannot check them.
-show_sub_messages should call show_sub_message.
+** Graphviz display code thoughts
+The code for the --graph option is over two files: print_graph, and
+graphviz. This is because Bison used to also produce VCG graphs, but since
+this is no longer true, maybe we could consider these files for fusion.
+
+An other consideration worth noting is that print_graph.c (correct me if I
+am wrong) should contain generic functions, whereas graphviz.c and other
+potential files should contain just the specific code for that output
+format. It will probably prove difficult to tell if the implementation is
+actually generic whilst only having support for a single format, but it
+would be nice to keep stuff a bit tidier: right now, the construction of the
+bitset used to show reductions is in the graphviz-specific code, and on the
+opposite side we have some use of \l, which is graphviz-specific, in what
+should be generic code.
+
+Little effort seems to have been given to factoring these files and their
+rint{,-xml} counterpart. We would very much like to re-use the pretty format
+of states from .output for the graphs, etc.
+
+Also, the underscore in print_graph.[ch] isn't very fitting considering the
+dashes in the other filenames.
+
+Since graphviz dies on medium-to-big grammars, maybe consider an other tool?
+
+** push-parser
+Check it too when checking the different kinds of parsers.  And be
+sure to check that the initial-action is performed once per parsing.

 
 ** m4 names
 b4_shared_declarations is no longer what it is.  Make it
 b4_parser_declaration for instance.
 
 
 ** m4 names
 b4_shared_declarations is no longer what it is.  Make it
 b4_parser_declaration for instance.
 

-** glr.cc: %defines
-it should not be mandatory.
+** yychar in lalr1.cc
+There is a large difference bw maint and master on the handling of
+yychar (which was removed in lalr1.cc).  See what needs to be
+back-ported.
+
+
+    /* User semantic actions sometimes alter yychar, and that requires
+       that yytoken be updated with the new translation.  We take the
+       approach of translating immediately before every use of yytoken.
+       One alternative is translating here after every semantic action,
+       but that translation would be missed if the semantic action
+       invokes YYABORT, YYACCEPT, or YYERROR immediately after altering
+       yychar.  In the case of YYABORT or YYACCEPT, an incorrect
+       destructor might then be invoked immediately.  In the case of
+       YYERROR, subsequent parser actions might lead to an incorrect
+       destructor call or verbose syntax error message before the
+       lookahead is translated.  */
+
+    /* Make sure we have latest lookahead translation.  See comments at
+       user semantic actions for why this is necessary.  */
+    yytoken = yytranslate_ (yychar);
+

 
 ** stack.hh
 Get rid of it.  The original idea is nice, but actually it makes
 the code harder to follow, and uselessly different from the other
 skeletons.
 
 
 ** stack.hh
 Get rid of it.  The original idea is nice, but actually it makes
 the code harder to follow, and uselessly different from the other
 skeletons.
 

-** Variable names.
-What should we name `variant' and `lex_symbol'?
-

 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
 
 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
 


@@ -44,9 +85,6 @@ since it is no longer bound to a particular parser, it's just a
 ** Rename LR0.cc
 as lr0.cc, why upper case?
 
 ** Rename LR0.cc
 as lr0.cc, why upper case?
 

-** bench several bisons.
-Enhance bench.pl with %b to run different bisons.
-

 * Various
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 * Various
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token


@@ -110,12 +148,6 @@ really possible?  The test suite does not exercise this case.
 This shows that it would be interesting to manage to install skeleton
 coverage analysis to the test suite.
 
 This shows that it would be interesting to manage to install skeleton
 coverage analysis to the test suite.
 

-** Table definitions
-It should be very easy to factor the definition of the various tables,
-including the separation bw declaration and definition.  See for
-instance b4_table_define in lalr1.cc.  This way, we could even factor
-C vs. C++ definitions.
-

 * From lalr1.cc to yacc.c
 ** Single stack
 Merging the three stacks in lalr1.cc simplified the code, prompted for
 * From lalr1.cc to yacc.c
 ** Single stack
 Merging the three stacks in lalr1.cc simplified the code, prompted for


@@ -144,13 +176,13 @@ part of $default.  Should we make the two reductions explicit, or just
 keep $default?  See the following point.
 
 ** Disabled Reductions
 keep $default?  See the following point.
 
 ** Disabled Reductions

-See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+See 'tests/conflicts.at (Defaulted Conflicted Reduction)', and decide

 what we want to do.
 
 ** Documentation
 Extend with error productions.  The hard part will probably be finding
 the right rule so that a single state does not exhibit too many yet
 what we want to do.
 
 ** Documentation
 Extend with error productions.  The hard part will probably be finding
 the right rule so that a single state does not exhibit too many yet

-undocumented ``features''.  Maybe an empty action ought to be
+undocumented ''features''.  Maybe an empty action ought to be

 presented too.  Shall we try to make a single grammar with all these
 features, or should we have several very small grammars?
 
 presented too.  Shall we try to make a single grammar with all these
 features, or should we have several very small grammars?
 


@@ -211,9 +243,9 @@ into
         exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some
         exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some

-grammars.  I can't find the papers.  In particular the book `LR
+grammars.  I can't find the papers.  In particular the book 'LR

 parsing: Theory and Practice' is impossible to find, but according to
 parsing: Theory and Practice' is impossible to find, but according to

-`Parsing Techniques: a Practical Guide', it includes information about
+'Parsing Techniques: a Practical Guide', it includes information about

 this issue.  Does anybody have it?
 
 
 this issue.  Does anybody have it?
 
 


@@ -241,9 +273,6 @@ Paul notes:
         tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
         the source code.  This should get fixed.
 
         tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
         the source code.  This should get fixed.
 

-* --graph
-Show reductions.
-

 * Broken options ?
 ** %token-table
 ** Skeleton strategy
 * Broken options ?
 ** %token-table
 ** Skeleton strategy


@@ -340,7 +369,7 @@ End:
 
 -----
 
 
 -----
 

-Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
+Copyright (C) 2001-2004, 2006, 2008-2014 Free Software Foundation, Inc.

 
 This file is part of Bison, the GNU Compiler Compiler.
 
 
 This file is part of Bison, the GNU Compiler Compiler.