X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/1a4648ff0d72c384f6fbfc46d9f23bbb28ca9300..cc9305dd68c95c9d9c279ca2b2d6330078bf664c:/TODO?ds=inline diff --git a/TODO b/TODO index 62622a61..a2057afb 100644 --- a/TODO +++ b/TODO @@ -1,11 +1,63 @@ -*- outline -*- -* tokendefs -This muscle should not exist: the information it contains should be -available from the rest of bison. Once the information public, get -rid of it. +* Unit rules +Maybe we could expand unit rules, i.e., transform -* Broken options ?. + exp: arith | bool; + arith: exp '+' exp; + bool: exp '&' exp; + +into + + exp: exp '+' exp | exp '&' exp; + +when there are no actions. This can significantly speed up some +grammars. + +* Useless rules +We have all the needed material to actually remove them. Do it. +Or maybe not, but at least do not include them in the automaton. + +* read_pipe.c +This is not portable to DOS for instance. Implement a more portable +scheme. Sources of inspiration include GNU diff, and Free Recode. + +* NEWS +Sort from 1.31 NEWS. + +* Prologue +The %union is declared after the user C declarations. It can be +a problem if YYSTYPE is declared after the user part. [] + +Actually, the real problem seems that the %union ought to be output +where it was defined. For instance, in gettext/intl/plural.y, we +have: + + %{ + ... + #include "gettextP.h" + ... + %} + + %union { + unsigned long int num; + enum operator op; + struct expression *exp; + } + + %{ + ... + static int yylex PARAMS ((YYSTYPE *lval, const char **pexp)); + ... + %} + +Where the first part defines struct expression, the second uses it to +define YYSTYPE, and the last uses YYSTYPE. Only this order is valid. + +* --graph +Show reductions. [] + +* Broken options ? ** %no-lines [ok] ** %no-parser [] ** %pure-parser [] @@ -23,9 +75,6 @@ Must we keep %no-parser? %token-table? *** New skeletons. [] -* src/macrotab.[ch] -Removing warnings when compiling. (gcc-warnings). [ok] - * src/print_graph.c Find the best graph parameters. [] @@ -36,7 +85,63 @@ informations about ERROR_VERBOSE. [] skeleton muscles. [] %skeleton. [] -* testsuite. -** tests/reduce.at [ok] +* testsuite ** tests/pure-parser.at [] New tests. + +* Debugging parsers + +From Greg McGary: + +akim demaille <akim.demaille@epita.fr> writes: + +> With great pleasure! Nonetheless, things which are debatable +> (or not, but just `big') should be discuss in `public': something +> like help- or bug-bison@gnu.org is just fine. Jesse and I are there, +> but there is also Jim and some other people. + +I have no idea whether it qualifies as big or controversial, so I'll +just summarize for you. I proposed this change years ago and was +surprised that it was met with utter indifference! + +This debug feature is for the programs/grammars one develops with +bison, not for debugging bison itself. I find that the YYDEBUG +output comes in a very inconvenient format for my purposes. +When debugging gcc, for instance, what I want is to see a trace of +the sequence of reductions and the line#s for the semantic actions +so I can follow what's happening. Single-step in gdb doesn't cut it +because to move from one semantic action to the next takes you through +lots of internal machinery of the parser, which is uninteresting. + +The change I made was to the format of the debug output, so that it +comes out in the format of C error messages, digestible by emacs +compile mode, like so: + +grammar.y:1234: foo: bar(0x123456) baz(0x345678) + +where "foo: bar baz" is the reduction rule, whose semantic action +appears on line 1234 of the bison grammar file grammar.y. The hex +numbers on the rhs tokens are the parse-stack values associated with +those tokens. Of course, yytype might be something totally +incompatible with that representation, but for the most part, yytype +values are single words (scalars or pointers). In the case of gcc, +they're most often pointers to tree nodes. Come to think of it, the +right thing to do is to make the printing of stack values be +user-definable. It would also be useful to include the filename & +line# of the file being parsed, but the main filename & line# should +continue to be that of grammar.y + +Anyway, this feature has saved my life on numerous occasions. The way +I customarily use it is to first run bison with the traces on, isolate +the sequence of reductions that interests me, put those traces in a +buffer and force it into compile-mode, then visit each of those lines +in the grammar and set breakpoints with C-x SPACE. Then, I can run +again under the control of gdb and stop at each semantic action. +With the hex addresses of tree nodes, I can inspect the values +associated with any rhs token. + +You like? + +* input synclines +Some users create their foo.y files, and equip them with #line. Bison +should recognize these, and preserve them.