This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc's C parser bitten by error recovery changes in bison 1.50
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Akim Demaille <akim at epita dot fr>
- Cc: gcc-bugs at gcc dot gnu dot org, help-bison at gnu dot org,Paul Hilfinger <Hilfinger at cs dot berkeley dot edu>
- Date: Wed, 16 Oct 2002 00:59:28 -0700
- Subject: Re: gcc's C parser bitten by error recovery changes in bison 1.50
- References: <20021016020117.GQ15067@codesourcery.com> <mv4of9ug6pe.fsf@nostromo.lrde.epita.fr>
On Wed, Oct 16, 2002 at 09:53:49AM +0200, Akim Demaille wrote:
> | Two questions:
> |
> | (for gcc-bugs:) Do we care? This test case is just checking that the
> | compiler doesn't crash on wildly erroneous input. The errors are all
> | enumerated so that dg.exp will be happy, but we could just shove a
> | { dg-excess-errors } in there and be done with it. The exact set of
> | errors isn't, IMO, all that interesting, and the new C++ parser should
> | do a _lot_ better.
> |
> | (for help-bison:) Assuming that we do care, how should the .y file be
> | modified so that 1.35 and 1.50 behave the same way?
>
> Wow... I do hope that you don't care :( But if you really do want to
> do that, you want to apply a patch similar to the reverse of:
Um, I think you misunderstand. Assuming that we care, I don't want to
change bison.simple. I want to adjust the rules in GCC's .y file so
that it behaves the same way under both error recovery schemes.
zw