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: Mon, 6 Feb 2006 19:02:16 -0500 (EST)

On Mon, 6 Feb 2006, Akim Demaille wrote:

> >>> "Joel" == Joel E Denny <address@hidden> writes:
> 
>  > If we're worried that some users won't want --yacc but will still
>  > want an implicit $$ = $1 for explicit actions, --yacc could accept
>  > options to specify exactly which yacc features should be
>  > implemented.  For example:
>   
>  >   --yacc=auto_lhs_value,filenames
>  >   --yacc=filenames
>  >   --yacc
> 
>  > where the last usage implies all yacc features.  This approach
>  > makes the subtle hint that implicit $$ = $1 before explicit actions
>  > is simply an old and unfortunate idea.
>
> I agree with the semantics, but dislike the syntax.  To be more
> standard, -W/--warnings seems a better option.  --yacc would be an
> alias for a set of warnings.

I do like the idea of a -W flag.  And it seems I made a mistake in my 
rationale for `auto_lhs_value'....

I suggested --yacc=... as a way to select specific yacc compatibility 
features that are not concerned solely with warnings.  For example, I was 
still thinking of our old problem of token #define's in the header when 
using "yacc.c".  yacc-style filenames is another.

I had thought of no_auto_lhs_value as a way to completely remove $$ = $1 
for explicit actions... not just remove the warnings.  I thought this was 
important because of Hans's overloaded operator= argument.  Now that I've 
thought about it harder, this argument doesn't make sense for bison.  
You're not allowed to write your own copy assignment operator for union 
members.  Anyone who writes a copy assignment operator for a #define'd 
YYSTYPE is just asking for trouble since yylval is copied repeatedly.  In 
summary, when yacc compatibility is off, it seems fine to just warn about 
$$ and $1 for explicit actions rather than completely removing the 
implicit $$ = $1.

Anyway, if --yacc=... ever catches on, I could imagine a --yacc option 
called something like `compatible-warnings' to serve as your alias for 
disabling all yacc-incompatible warnings.  For example:

  --yacc=filenames,token-defines,compatible-warnings

This:

  --yacc

would be equivalent to selecting all yacc compatibility options.

Joel




reply via email to

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