mirror of
https://git.savannah.gnu.org/git/bison.git
synced 2026-03-09 12:23:04 +00:00
680e8701b5
* src/output.c (output_table_data): Return the longest number. (prepare_tokens): Output `token_number_max'). * data/bison.simple, data/bison.c++ (b4_sint_type, b4_uint_type): New. Use them to define yy_token_number_type/TokenNumberType. Use this type for yytranslate. * tests/torture.at (Big triangle): Push the limit from 124 to 253. * tests/regression.at (Web2c Actions): Adjust.
149 lines
4.4 KiB
Plaintext
149 lines
4.4 KiB
Plaintext
-*- outline -*-
|
|
|
|
* Unit rules
|
|
Maybe we could expand unit rules, i.e., transform
|
|
|
|
exp: arith | bool;
|
|
arith: exp '+' exp;
|
|
bool: exp '&' exp;
|
|
|
|
into
|
|
|
|
exp: exp '+' exp | exp '&' exp;
|
|
|
|
when there are no actions. This can significantly speed up some
|
|
grammars.
|
|
|
|
* Huge Grammars
|
|
Currently, not only is Bison unable to handle huge grammars because of
|
|
internal limitations (see test `big triangle'). Push the limit beyond
|
|
253. Be my guest: fix this!
|
|
|
|
* 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 []
|
|
** %token-table []
|
|
** Options which could use parse_dquoted_param ().
|
|
Maybe transfered in lex.c.
|
|
*** %skeleton [ok]
|
|
*** %output []
|
|
*** %file-prefix []
|
|
*** %name-prefix []
|
|
|
|
** Skeleton strategy. []
|
|
Must we keep %no-parser?
|
|
%token-table?
|
|
*** New skeletons. []
|
|
|
|
* src/print_graph.c
|
|
Find the best graph parameters. []
|
|
|
|
* doc/bison.texinfo
|
|
** 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 <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.
|