[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %destructor declared by semantic type
From: |
Joel E. Denny |
Subject: |
Re: %destructor declared by semantic type |
Date: |
Wed, 21 Jun 2006 18:16:30 -0400 (EDT) |
On Wed, 21 Jun 2006, Joel E. Denny wrote:
> That persuades me to believe that Akim's right: $<T>$ and $<T>n should be
> thought of like unsafe C-style casts, and Bison should ignore them when
> choosing destructors. It's much easier that way.
Before I trash that part of the old proposal entirely, there's one idea
from it that might still be worthwhile. Again, the old proposal was here:
http://lists.gnu.org/archive/html/bison-patches/2006-02/msg00067.html
I wrote:
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.
I am now imagining (bizarre?) uses of such a $<T>$ where the user has
guaranteed that the parser need not ever invoke a destructor for the final
value of $$. Thus, I'm thinking the above should be a warning (not an
error) and should be turned off by default. We've been tossing around the
idea of adding something like a -Wall flag to Bison, and maybe this
warning would be helpful when the user specifies -Wall.
I had proposed that Bison would only check for this problem for $<T>$ in
final actions. However, I think it shouldn't be so limited:
1. Given Akim's idea for declaring types for midrule values, Bison could
check $<T>$ in midrule actions as well.
2. Bison could also check $<T>n in midrule actions since a user could
reassign a $<T>n there.
3. I can't see a reason to check $<T>n in final actions since the
Bison-generated code is guaranteed not to invoke the destructor for it
anyway.
In summary, there may be cases where the user would like to know if he's
accidentally placed values that need destructors into symbols that have no
destructors.
What do you think?
Joel