X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/e83d80b8ed8587fd05437d33f2011403f55f1f9d..b4c4ccc2b3b546a665f65a619af0a60e0dbacf50:/TODO diff --git a/TODO b/TODO index a46c66f1..a2057afb 100644 --- a/TODO +++ b/TODO @@ -1,15 +1,64 @@ -*- outline -*- -* src/reader.c -Check and cleanup for CPP-out code. [ok] +* Unit rules +Maybe we could expand unit rules, i.e., transform -* src/output.c -Check and cleanup for CPP-out code. [ok] -** %%input-line is not correct at this time. -Rely with bison.simple. + exp: arith | bool; + arith: exp '+' exp; + bool: exp '&' exp; -* Broken options ?. -** %no-lines [] +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 [] ** %semantic-parser [] @@ -22,19 +71,77 @@ Maybe transfered in lex.c. *** %name-prefix [] ** Skeleton strategy. [] -Useful for %no_parser. [] +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. [] * doc/bison.texinfo -Update informations about ERROR_VERBOSE. [] -Add explainations about skeleton muscles. [] -Add explainations about %skeleton. [] +** Update +informations about ERROR_VERBOSE. [] +** Add explainations about +skeleton muscles. [] +%skeleton. [] + +* testsuite +** tests/pure-parser.at [] +New tests. + +* Debugging parsers + +From Greg McGary: + +akim demaille 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? -* testsuite. -** tests/reduce.at [ok] +* input synclines +Some users create their foo.y files, and equip them with #line. Bison +should recognize these, and preserve them.