[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cp/parse.y:2120: invalid value: $3

From: Akim Demaille
Subject: cp/parse.y:2120: invalid value: $3
Date: 29 Apr 2002 14:24:48 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)


A recent fix in CVS Bison results in its refusing the current G++
grammar.  It chokes on the following snippet (CVS gcc/cp/parse.y,
around line 2117):

| nomods_initdcl0:
|           notype_declarator maybeasm
|             { /* Set things up as initdcl0_innards expects.  */
| ===>        $<ttype>3 = $2;
|             $2 = $1; 
|               $<ftype>1.t = NULL_TREE;
|             $<ftype>1.lookups = NULL_TREE; }
|           initdcl0_innards 
|             {}
|       | constructor_declarator maybeasm maybe_attribute
|               { tree d = parse_decl0 ($1, NULL_TREE, NULL_TREE, $3, 0);
|                 parse_end_decl (d, NULL_TREE, $2); }
|       ;

Bison now says:

% bison parse.y
parse.y:2120: invalid value: $3

The problem is serious: the assignment violates POSIX (it should read
$<ttype>$), and anyway, could not have worked properly: the first
thing the parser does after having executed this action is replacing
the current slot (which turns out to be exactly that of $3) with $$,
which is uninitialized (well, actually, it's $1).

As far as Bison is concerned, I'd like the GCC team to tell me what
they would prefer:

1. I release this Bison as is, fixed, and it will die on current G++.

2. I introduce a temporary hack to accept this grammar, and still
   produce the old broken code.

3. I introduce a temporary hack to accept this grammar, and produce
   the *intended* code.  I will put a warning though.

Of course, I prefer 1.  Option 3 is tempting, but given that this code
is probably old, making it work might making it fail.  Or maybe it's
just dead code, I don't know.  In any case, I suppose the code should
be audited.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]