[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: too many warnings from Bison CVS for Pike
From: |
Joel E. Denny |
Subject: |
Re: too many warnings from Bison CVS for Pike |
Date: |
Tue, 14 Feb 2006 05:04:34 -0500 (EST) |
On Mon, 13 Feb 2006, Paul Eggert wrote:
> "Joel E. Denny" <address@hidden> writes:
>
> > This confusion makes me wonder if %destructor really should be by type
>
> To be honest I'm surprised it's not done by type. However, it may
> be too late to change this now. Or perhaps we could add a new
> feature %type-destructor that is by type.
Or just accept either using %destructor. For example:
%destructor { free ($$); } symbol1 <type1> <type2>
If a symbol has a type, I think any destructor declared for the symbol
should override any destructor declared for the type since the former is
more specific.
> > and if $<type>$ should dynamically record a new type for that state
> > on the stack.
>
> That might make sense, for %type-destructor anyway.
>
> But it is getting a bit complicated.
Yes, dynamic types would be complicated.
> It might be better just to leave
> things be, and warn users that $<type>$ and destructors don't mix.
Sometimes they do mix. For example, a single %destructor might be
appropriate for all types:
%destructor { free ($$); }
In this case, the user can feel free to use $<type>$ all he wants.
> (The problem is not limited to midrule actions, no?)
Given the possibility above, maybe this problem should be in the user's
hands for non-midrule actions.
Actually, maybe this problem can be handled statically after all. Assume
%destructor can be declared for both symbols and types. Consider the
following approach:
1. If a LHS nonterminal has a declared destructor (whether declared just
for it or inherited from its declared type), then bison would use that
destructor regardless of any $<T>$ in any user action and regardless of
any destructor declared for T. The assumption would be that the user has
guaranteed that the LHS nonterminal's destructor handles all possible
types. T having its own destructor is reasonable given that other
semantic values might need it even though this one doesn't.
2. If a LHS nonterminal has no declared destructor but there exists a
$<T>$ in one of its actions such that T has a destructor, then bison would
issue a warning/error letting the user know that the destructor will not
be executed for this LHS nonterminal.
3. In any midrule action, for every pair $<T1>$ and $<T2>$, if either T1
or T2 has a destructor but they do not both appear in the same %destructor
declaration, bison would issue a warning/error since it cannot compute
which destructor to use for the midrule's value.
4. In any midrule action where #3 is not a problem, the destructor is
uniquely determined, and bison would use that destructor for the midrule's
value.
Note that I'm not so inclined to worry about $<T>n (referring either to a
midrule value or to a nonterminal). First, $<T>$ is the defining point,
so it seems reasonable that only it influences the destructor. Second,
$<T>n appears after the time when bison might actually generate destructor
calls on the semantic value. So, the user can play with whatever union
members he wants here.
Joel
- Re: too many warnings from Bison CVS for Pike, (continued)
- Message not available
- (no subject), haberg, 2006/02/06
Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/02/13