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

[Akim Demaille]

Hi Tom,

> Le 8 sept. 2021 à 20:56, Tom Shields via Bug fixes and other improvements to 
> Bison <bison-patches@gnu.org> a écrit :
> 
> My earlier approach to using the anonymous namespace in glr2.cc 
> <http://glr2.cc/> to resolve linker errors worked just fine with “%union”,  
> 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.

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’t 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’t 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=custom 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’ve made to glr2.cc <http://glr2.cc/>:

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

Cheers!