This commit is contained in:
Akim Demaille
2002-04-22 12:36:15 +00:00
parent 216eb8c9f2
commit 7655146399
2 changed files with 122 additions and 36 deletions

81
TODO
View File

@@ -1,5 +1,50 @@
-*- outline -*-
* URGENT: 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.
Note that we have the same problem with GCC.
I suggest splitting the prologue into pre-prologue and post-prologue.
The reason is that:
1. we keep language independance as it is the skeleton that joins the
two prologues (there is no need for the engine to encode union yystype
and to output it inside the prologue, which breaks the language
independance of the generator)
2. that makes it possible to have several %union in input. I think
this is a pleasant (but useless currently) feature, but in the future,
I want a means to %include other bits of grammars, and _then_ it will
be important for the various bits to define their needs in %union.
* Coding system independence
Paul notes:
@@ -171,40 +216,6 @@ critical for user data: when aborting a parsing, when handling the
error token etc., we often throw away yylval without giving a chance
of cleaning it up to the user.
* 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.
Note that we have the same problem with GCC.
* --graph
Show reductions. []
@@ -400,7 +411,7 @@ The way I solved this was to define a macro YYACT_EPILOGUE that would
be invoked after the action. For reasons of symmetry I also added
YYACT_PROLOGUE. Although I had no use for that I can envision how it
might come in handy for debugging purposes.
All is needed is to add
All is needed is to add
#if YYLSP_NEEDED
YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));