bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggested Fix/Change


From: Akim Demaille
Subject: Re: Suggested Fix/Change
Date: Sun, 20 Dec 2020 16:54:55 +0100

Hi Jot,

> Le 18 déc. 2020 à 10:16, Jot Dot <jotdot@shaw.ca> a écrit :
> 
> Tools Used:  bison (GNU Bison) 3.7.1
> 
> I was attempting to convert my lalr(1) code to glr.
> I know that the current glr version only uses POD.
> I was using variants and lalr(1). When changing the
> source to use glr I completely missed removing one line:
> 
> %define api.token.constructor
> 
> Naturally it must be removed for glr.
> 
> ISSUE:
> 
> With the %define in the code, Bison still processes the
> grammar and outputs a report that is exactly the same
> as when that %define is not in the source, and then silently
> fails with an error code 1 and leaves two temporary
> files around.
> 
> The problem is that (visually) it appears there is
> no issue at all! Even the --verbose option has no effect.

You have been very unlucky: bison does check whether your %define
variables are used or not by the skeleton.  So you should have had
the warning, I'm sorry you didn't.

The reason you didn't have it is that there was some ongoing work
to support it with glr.cc, but it does not work.  And if you look
at the archives of bison-patches, you'll see that there is a lot
of activity currently on glr2.cc which should fill the gap and add
proper support for GLR in C++.

I will address your request at some point.  Currently the hot topic
is the completion of glr2.cc.

Cheers!


reply via email to

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