bison-patches
[Top][All Lists]
Advanced

[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




reply via email to

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