scan-code: avoid compiler warnings

[bison.git] / TODO

diff --git a/TODO b/TODO
index 0a4aef400fef77539ec4fb0f986b4a5e0d8d9fa0..376ec1d7b97284197a00e0474855640c36c9a309 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,45 @@
 -*- outline -*-
 
+* Short term
+** Use b4_symbol in all the skeleton
+Then remove the older system, including the tables generated by
+output.c
+
+** Update the documentation on gnu.org
+
+** Get rid of fake #lines [Bison: ...]
+Possibly as simple as checking whether the column number is nonnegative.
+
+I have seen messages like the following from GCC.
+
+<built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
+
+
+** Discuss about %printer/%destroy in the case of C++.
+It would be very nice to provide the symbol classes with an operator<<
+and a destructor.  Unfortunately the syntax we have chosen for
+%destroy and %printer make them hard to reuse.  For instance, the user
+is invited to write something like
+
+   %printer { debug_stream() << $$; } <my_type>;
+
+which is hard to reuse elsewhere since it wants to use
+"debug_stream()" to find the stream to use.  The same applies to
+%destroy: we told the user she could use the members of the Parser
+class in the printers/destructors, which is not good for an operator<<
+since it is no longer bound to a particular parser, it's just a
+(standalone symbol).
+
+** Rename LR0.cc
+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
@@ -14,6 +54,45 @@ number for the error token, which POSIX wants to be 256, but which
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 
+Also, why don't we output the token name of the error token in the
+output?  It is explicitly skipped:
+
+      /* Skip error token and tokens without identifier.  */
+      if (sym != errtoken && id)
+
+Of course there are issues with name spaces, but if we disable we have
+something which seems to be more simpler and more consistent instead
+of the special case YYERRCODE.
+
+   enum yytokentype {
+     error = 256,
+     // ...
+   };
+
+
+We could (should?) also treat the case of the undef_token, which is
+numbered 257 for yylex, and 2 internal.  Both appear for instance in
+toknum:
+
+  const unsigned short int
+  parser::yytoken_number_[] =
+  {
+       0,   256,   257,   258,   259,   260,   261,   262,   263,   264,
+
+while here
+
+   enum yytokentype {
+     TOK_EOF = 0,
+     TOK_EQ = 258,
+
+so both 256 and 257 are "mysterious".
+
+  const char*
+  const parser::yytname_[] =
+  {
+  "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
+
+
 ** YYFAIL
 It is seems to be *really* obsolete now, shall we remove it?
 
@@ -92,12 +171,8 @@ management is performed once instead of three times).  I suggest that
 we do the same in yacc.c.
 
 ** yysyntax_error
-In lalr1.cc we invoke it with the translated lookahead (yytoken), and
-yacc.c uses yychar.  I don't see why.
-
-** yysyntax_error
-The use of switch to select yyfmt in lalr1.cc seems simpler than
-what's done in yacc.c.
+The code bw glr.c and yacc.c is really alike, we can certainly factor
+some parts.
 
 * Header guards
 
@@ -231,7 +306,8 @@ this issue.  Does anybody have it?
 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 
-
+** %printer
+Wow, %printer is not documented.  Clearly mark YYPRINT as obsolete.
 
 * Java, Fortran, etc.