* URGENT: Documenting C++ output
Write a first documentation for C++ output.
+* Report and GLR
+How would Paul like to display the conflicted actions? In particular,
+what when two reductions are possible on a given lookahead, but one is
+part of $default. Should we make the two reductions explicit, or just
+keep $default? See the following point.
+
+* Report and Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
+
* value_components_used
Was defined but not used: where was it coming from? It can't be to
check if %union is used, since the user is free to $<foo>n on her
* documentation
Explain $axiom (and maybe change its name: BTYacc names it `goal',
byacc `$accept' probably based on AT&T Yacc, Meta `Start'...).
-Complete the glossary (item, axiom, ?).
+Complete the glossary (item, axiom, ?). Should we also rename `$'?
+BYacc uses `$end'. `$eof' is attracting, but after all we may be
+parsing a string, a stream etc.
* Error messages
Some are really funky. For instance
is really weird. Revisit them all.
* Report documentation
-Extend with error. The hard part will probably be finding the right
-rule so that a single state does not exhibit to many yet undocumented
-``features''. Maybe an empty action ought to be presented too. Shall
-we try to make a single grammar with all these features, or should we
-have several very small grammars?
+Extend with error productions. The hard part will probably be finding
+the right rule so that a single state does not exhibit too many yet
+undocumented ``features''. Maybe an empty action ought to be
+presented too. Shall we try to make a single grammar with all these
+features, or should we have several very small grammars?
* Documentation
Some history of Bison and some bibliography would be most welcome.
** 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.
Copyright (C) 2001, 2002 Free Software Foundation, Inc.
-This file is part of GNU Autoconf.
+This file is part of GNU Bison.
-GNU Autoconf is free software; you can redistribute it and/or modify
+GNU Bison is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
-GNU Autoconf is distributed in the hope that it will be useful,
+GNU Bison is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
-along with autoconf; see the file COPYING. If not, write to
+along with Bison; see the file COPYING. If not, write to
the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.
projects / bison.git / blobdiff