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

Hi Tom,

> Le 8 sept. 2021 =C3=A0 20:56, Tom Shields via Bug fixes and other =
improvements to Bison <[email protected]> a =C3=A9crit :
>=20
> 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.
>=20
> Using Bison variants, my application linked with no diagnostics, but =
failed at runtime in a mysterious (to me) way within the parsers.

I am not surprised: you must have tons of ODR violations.  Because you =
don't use api.namespace, but just api.parser.class, you have symbols =
defined multiple times in the *.cc files, hence in the *.o files, hence =
the linkers is free to get rid of these "duplicates" and just pick one. =
It's made even worse by glr2.cc alone, which also defines many symbols =
in the implementation file in no namespace.  And using the unnamed =
namespace is also quite dangerous if you use them in the header file.


> 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.

Look for "ODR" on the Internet.

> 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.

As I mentioned in private email, I'm also working on this on my side.  =
Currently I have parse.error=3Dcustom that works well in glr2.cc.  I'm =
also addressing these linking issue, and I agree the way to go is inner =
classes.  I'm not too happy with this, since it's extremely verbose, and =
it generates gigantic symbols, but...  The only alternative would be to =
consider that it is invalid to have two parsers in the same =
api.namespace, differing only in their api.parser.class.

Still, I have to finish 3.8, and then I'll start pushing what I have on =
glr2.cc.

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

Sorry, but we don't get your attachments.  Not this one, nor the =
previous one.

Cheers!