Re: Problems with the new bison glr2.cc skeleton in the Savannah Git repository

Using the glr2.cc <http://glr2.cc/> file that generated the  =E2=80=98git =
diff=E2=80=99 I provided in my previous email generates multiple parsers =
for my Bison GLR application that compile and link with no errors, but =
the resulting executable goes into an infinite loop.

I have no idea why that earlier version loops, but the attached =E2=80=98g=
it diff=E2=80=99 of a revised glr2.cc <http://glr2.cc/> generates a =
correctly working version of my application. This revision wraps =
additional classes in the anonymous namespace.



        =20
Powered by Mailbutler =
<https://www.mailbutler.io/?utm_source=3Dwatermark&utm_medium=3Demail&utm_=
campaign=3Dwatermark-essential-email>, the email extension that does it =
all

> On Sep 2, 2021, at 1:20 PM, Tom Shields =
<[email protected]> wrote:
>=20
> My Bison GLR application uses multiple parsers linked into a single =
executable generated with the same =E2=80=98api.namespace' value but =
with different =E2=80=98api.parser.class' values.
>=20
> I=E2=80=99m currently working to convert to the C++ GLR skeleton, and =
the glr.cc <http://glr.cc/> skeleton in the bison 3.7.6 release has a =
problem (previously reported to [email protected] =
<mailto:[email protected]>). Based on the response to that bug report =
from Akim Demaille, I tried out the new glr2.cc <http://glr2.cc/> =
skeleton found in the latest version of Bison on the Savannah Git =
repository. As noted by Akim in his response to me, the glr2.cc =
<http://glr2.cc/> skeleton doesn=E2=80=99t (yet) support '%define =
parse.error custom=E2=80=99, so I did a quick&dirty copy&paste to add =
that missing feature, based on the existing support for =E2=80=98=E2=80=99=
%define parse.error custom' in the glr.c skeleton and got duplicated =
symbol linker errors for the following symbols:
>=20
> create_state_set_index(long)
> glr_state::firstVal()
> glr_state::firstVal() const
> glr_state::indexIn(glr_stack_item const*) const
> glr_state::pred()
> glr_state::pred() const
> glr_state::setFirstVal(semantic_option const*)
> glr_state::setPred(glr_state const*)
> semantic_option::indexIn(glr_stack_item const*) const
> semantic_option::next()
> semantic_option::next() const
> semantic_option::setNext(semantic_option const*)
> semantic_option::setState(glr_state const*)
> semantic_option::state()
> semantic_option::state() const
>=20
> Adding =E2=80=98static=E2=80=99 to 'create_state_set_index' and =
wrapping the =E2=80=98glr_state=E2=80=99 and =E2=80=98semantic_option=E2=80=
=99 classes in the anonymous namespace eliminates the problems.
>=20
> Attached is a 'git diff=E2=80=99 of my quick&dirty version of glr2.cc =
<http://glr2.cc/>.
>=20
> As I=E2=80=99m not by any means a C++ expert, and as Akim tells me he =
is working on adding support for =E2=80=98%define parse.error custom=E2=80=
=9D himself, I don=E2=80=99t actually consider this as a patch =
submission. Rather, consider this more of a bug report against the =
developmental version of glr2.cc <http://glr2.cc/>.
>=20
> Regards,
>=20
> Tom Shields
> +1 214-287-9093
>=20
> <glr2.cc.diff>