]>
Commit | Line | Data |
---|---|---|
416bd7a9 MA |
1 | -*- outline -*- |
2 | ||
52d1aeee MA |
3 | * NEWS |
4 | Sort from 1.31 NEWS. | |
5 | ||
bcb05e75 MA |
6 | * Prologue |
7 | The %union is declared after the user C declarations. It can be | |
704a47c4 | 8 | a problem if YYSTYPE is declared after the user part. [] |
bcb05e75 | 9 | |
704a47c4 AD |
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. | |
bcb05e75 MA |
34 | |
35 | * --graph | |
36 | Show reductions. [] | |
37 | ||
704a47c4 | 38 | * Broken options ? |
c3995d99 | 39 | ** %no-lines [ok] |
04a76783 | 40 | ** %no-parser [] |
fbbf9b3b | 41 | ** %pure-parser [] |
04a76783 MA |
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 [] | |
ec93a213 | 50 | |
fbbf9b3b | 51 | ** Skeleton strategy. [] |
c3a8cbaa MA |
52 | Must we keep %no-parser? |
53 | %token-table? | |
fbbf9b3b | 54 | *** New skeletons. [] |
416bd7a9 | 55 | |
c111e171 | 56 | * src/print_graph.c |
31b53af2 | 57 | Find the best graph parameters. [] |
63c2d5de MA |
58 | |
59 | * doc/bison.texinfo | |
1a4648ff | 60 | ** Update |
c3a8cbaa | 61 | informations about ERROR_VERBOSE. [] |
1a4648ff | 62 | ** Add explainations about |
c3a8cbaa MA |
63 | skeleton muscles. [] |
64 | %skeleton. [] | |
eeeb962b | 65 | |
704a47c4 | 66 | * testsuite |
c3a8cbaa MA |
67 | ** tests/pure-parser.at [] |
68 | New tests. | |
0f8d586a AD |
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? |