Re: Another - Bison 1.35 works but Bison 1.50 Doesn't

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> Hm...  Are you sure we want this?  What does POSIX say?

Paul> POSIX says this of both $$ and $1:

Paul>    If type checking is enabled and the type of the value to be
Paul> assigned cannot be determined, a diagnostic message may be
Paul> generated.

Paul> So the message is optional for the default action "$$ = $1;".


OK.  Still, I'm not fond :(  I also matched Byacc's behavior, IIRC.
So just for means of portability to other Yacc's, I think this is a
regression.


Paul> I agree with you in general, but I'm not so sure about this
Paul> particular case.  To my mind, that warning was a bit like
Paul> warning about the C statement `close (0);'.  In both cases the
Paul> programmer is implicitly discarding a value.  But the GNU coding
Paul> standards ask programmers to not write an explicit cast to
Paul> (void) in the C case, implying that such a warning is bogus for
Paul> the C statement.  The Bison case seems similar to me.  Jim
Paul> Gifford supplied a real grammar where the warning was a false
Paul> alarm.  We don't have an exhaustive survey here by any means,
Paul> but I tend to think such cases will dominate the cases where the
Paul> warning is useful.

Paul> I suppose we could enable the extra warning as an option.  But
Paul> in the meantime I'd rather omit it.


>> I *fixed* a bug here, before Bison was not complaining for such
>> cases when there was a midrule action, that's the only difference
>> with 1.35.

Paul> Do you have a URL for the bug that you fixed?  The fixes
Paul> shouldn't collide, since the fix mentioned above affects only
Paul> the default action, not midrule actions.

What I mean is that I bet that the grammar Jim Gifford reported about
has *all* the other cases fixed but these, because (I have not
checked, this is just by memory) Bison used to check properly

        foo: bar baz;

but *not*

        foo: bar {} baz;

because the code was written in such a way that the test was fooled by
the presence of a mid-rule action.  That's what the following NEWS
item meant:

* Type clashes
  Previous versions don't complain when there is a type clash on
  the default action if the rule has a mid-rule action, such as in:

      %type <foo> bar
      %%
      bar: '0' {} '0';

  This is fixed.