[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!