Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-18 16:53:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update.

Browse Source
This commit is contained in:
Akim Demaille
2002-06-20 12:19:42 +00:00
parent 1ae7286376
commit 3424c3868f
1 changed files with 0 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
TODO
View File

@@ -158,59 +158,6 @@ skeleton muscles. []
** tests/pure-parser.at [] ** tests/pure-parser.at []
New tests. 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 * input synclines
Some users create their foo.y files, and equip them with #line. Bison Some users create their foo.y files, and equip them with #line. Bison
should recognize these, and preserve them. should recognize these, and preserve them.