TODO

   1 -*- outline -*-
   2
   3 * NEWS
   4 Sort from 1.31 NEWS.
   5
   6 * Prologue
   7 The %union is declared after the user C declarations. It can be
   8 a problem if YYSTYPE is declared after the user part.   []
   9
  10 Actually, the real problem seems that the %union ought to be output
  11 where it was defined.  For instance, in gettext/intl/plural.y, we
  12 have:
  13
  14         %{
  15         ...
  16         #include "gettextP.h"
  17         ...
  18         %}
  19
  20         %union {
  21           unsigned long int num;
  22           enum operator op;
  23           struct expression *exp;
  24         }
  25
  26         %{
  27         ...
  28         static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
  29         ...
  30         %}
  31
  32 Where the first part defines struct expression, the second uses it to
  33 define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.
  34
  35 * --graph
  36 Show reductions.        []
  37
  38 * Broken options ?
  39 ** %no-lines            [ok]
  40 ** %no-parser           []
  41 ** %pure-parser         []
  42 ** %semantic-parser     []
  43 ** %token-table         []
  44 ** Options which could use parse_dquoted_param ().
  45 Maybe transfered in lex.c.
  46 *** %skeleton           [ok]
  47 *** %output             []
  48 *** %file-prefix        []
  49 *** %name-prefix        []
  50
  51 ** Skeleton strategy.   []
  52 Must we keep %no-parser?
  53              %token-table?
  54 *** New skeletons.      []
  55
  56 * src/print_graph.c
  57 Find the best graph parameters. []
  58
  59 * doc/bison.texinfo
  60 ** Update
  61 informations about ERROR_VERBOSE.       []
  62 ** Add explainations about
  63 skeleton muscles.       []
  64 %skeleton.              []
  65
  66 * testsuite
  67 ** tests/pure-parser.at []
  68 New tests.
  69
  70 * Debugging parsers
  71
  72 From Greg McGary:
  73
  74 akim demaille <akim.demaille@epita.fr> writes:
  75
  76 > With great pleasure!  Nonetheless, things which are debatable
  77 > (or not, but just `big') should be discuss in `public': something
  78 > like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,
  79 > but there is also Jim and some other people.
  80
  81 I have no idea whether it qualifies as big or controversial, so I'll
  82 just summarize for you.  I proposed this change years ago and was
  83 surprised that it was met with utter indifference!
  84
  85 This debug feature is for the programs/grammars one develops with
  86 bison, not for debugging bison itself.  I find that the YYDEBUG
  87 output comes in a very inconvenient format for my purposes.
  88 When debugging gcc, for instance, what I want is to see a trace of
  89 the sequence of reductions and the line#s for the semantic actions
  90 so I can follow what's happening.  Single-step in gdb doesn't cut it
  91 because to move from one semantic action to the next takes you through
  92 lots of internal machinery of the parser, which is uninteresting.
  93
  94 The change I made was to the format of the debug output, so that it
  95 comes out in the format of C error messages, digestible by emacs
  96 compile mode, like so:
  97
  98 grammar.y:1234: foo: bar(0x123456) baz(0x345678)
  99
 100 where "foo: bar baz" is the reduction rule, whose semantic action
 101 appears on line 1234 of the bison grammar file grammar.y.  The hex
 102 numbers on the rhs tokens are the parse-stack values associated with
 103 those tokens.  Of course, yytype might be something totally
 104 incompatible with that representation, but for the most part, yytype
 105 values are single words (scalars or pointers).  In the case of gcc,
 106 they're most often pointers to tree nodes.  Come to think of it, the
 107 right thing to do is to make the printing of stack values be
 108 user-definable.  It would also be useful to include the filename &
 109 line# of the file being parsed, but the main filename & line# should
 110 continue to be that of grammar.y
 111
 112 Anyway, this feature has saved my life on numerous occasions.  The way
 113 I customarily use it is to first run bison with the traces on, isolate
 114 the sequence of reductions that interests me, put those traces in a
 115 buffer and force it into compile-mode, then visit each of those lines
 116 in the grammar and set breakpoints with C-x SPACE.  Then, I can run
 117 again under the control of gdb and stop at each semantic action.
 118 With the hex addresses of tree nodes, I can inspect the values
 119 associated with any rhs token.
 120
 121 You like?
 122
 123 * input synclines
 124 Some users create their foo.y files, and equip them with #line.  Bison
 125 should recognize these, and preserve them.