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

Over the last few days I updated my application's multiple Bison GLR =
parsers (and corresponding Flex levers) to use the =E2=80=9C%define =
api.value.type variant=E2=80=9D directive rather than the legacy Yacc =
"%union=E2=80=9D approach, converting the C data structures previously =
used to type the grammar symbols to C++ data structures implemented with =
"std::string=E2=80=9D and "std::list=E2=80=9D.

I=E2=80=99m doing this on a Mac mini with Apple=E2=80=99s ARM64 M1 chip, =
running macOS (Big Sur, 11.5.2) and Xcode 12.5.1.

My earlier approach to using the anonymous namespace in glr2.cc =
<http://glr2.cc/> to resolve linker errors worked just fine with =
=E2=80=9C%union=E2=80=9D,  passing all of the regression test suite =
cases.

Using Bison variants, my application linked with no diagnostics, but =
failed at runtime in a mysterious (to me) way within the parsers.

Under the debugger, I eventually discovered that the types at runtime of =
some of the internal parser data structures being passed around didn=E2=80=
=99t always match up with the particular executing parser. Not being an =
LLVM Clang guru, I have no clue as to why this was happening, and I =
didn=E2=80=99t even try to figure it out.

Rather, I was able to eliminate the weirdness by moving some of the =
glr2.cc <http://glr2.cc/> helper classes local to the parser class, and =
my application now runs through the regression test suite under macOS.

Here are the changes that I=E2=80=99ve made to glr2.cc =
<http://glr2.cc/>:

        =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



I make no claims other than that it currently works for my application. =
It would not surprise me to uncover additional problems when I =
eventually attempt to use the =E2=80=9C%define api.token.constructor=E2=80=
=9D directive.

When I get a chance (at the earliest, late next week), I=E2=80=99ll =
start running the regression test suite to check portability.

My normal portability testing process uses the latest distributed =
compilers plus any prebuilt versions of the GNU and LLVM compilers =
available (from Homebrew) on both my M1 and Intel Mac mini running macOS =
Big Sur (11.5.2), as well as Intel virtual machines running macOS =
Catalina (10.15.7) and Mojave (10.14.6). I also use the distributed =
compilers plus whatever prebuilt versions of the GNU and LLVM compilers =
are available for Linux (Ubuntu 21.04), Windows (Cygwin & Msys2, =
including MinGW) and Solaris (11.3, 11.4), on Intel virtual machines.

Regards,

Tom Shields
+1 214-287-9093

> On Sep 2, 2021, at 4:27 PM, Tom Shields =
<[email protected]> wrote:
>=20
> Using the glr2.cc <http://glr2.cc/> file that generated the  =E2=80=98gi=
t 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.
>=20
> I have no idea why that earlier version loops, but the attached =E2=80=98=
git 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
> <glr2.cc.diff>
>=20
>> On Sep 2, 2021, at 1:20 PM, Tom Shields =
<[email protected] =
<mailto:[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>
>=20