Re: too many warnings from Bison CVS for Pike

[Joel E. Denny]

On Mon, 6 Feb 2006, Akim Demaille wrote:

> >>> "Joel" == Joel E Denny <address@hidden> writes:
> 
>  > On Sun, 29 Jan 2006, Paul Eggert wrote:
> 
>  >> If we enabled these warnings via an option I don't think people
>  >> would object.
> 
> I recently came with the idea that more and more features should just
> be enabled by %require.

I do like this idea in principle.  That is, we may wish to force new 
features (for example, warnings) on the user because they are good 
practice.  The user can opt out with the understanding that he's 
regressing to an earlier release of bison.

When not specifying --yacc, whether $$ and $1 are considered used in an 
explicit action might be a bison backward compatibility issue.  Thus, the 
related warnings might be a candidate for control with %require.  Whether 
unused typed $n warnings are on (better way?) or off (old way) by default 
might be another candidate.  The previous lack of warnings for unused $n 
with destructor or for midrules can conveniently be placed in the bug 
category, in my opinion, and don't need %require.

> For instance, the discussion Joel and I had
> about the weird interface of yyerror in yacc.c (which depends on %pure
> and %locations in weird ways) should be resolved using some simple new
> directive, say %really-pure, itself enabled by default when %require
> is >= 2.2 (or whatever the release).

I still really like your idea about %error-report.  It seems so clean and 
easy to evolve.  Maybe %require could be used to determine whether 
%error-report or yyerror() is called (assuming no --yacc).  (By the way, 
upgrading to %error-report should be easy: just embed a call on your old 
yyerror().)

> That scheme should provide us with what we are looking for: both
> ensuring backward compatibility even when it's absurd (e.g., useless
> %expect), and promoting better practices.

%require's interaction with other flags and directives might get a little 
hairy to maintain at times, but maybe the ability to phase out old 
functionality gradually is worth it.

Joel