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

[Tom Shields]

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

I’m doing this on a Mac mini with Apple’s 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 “%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.

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.

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

         
Powered by Mailbutler 
<https://www.mailbutler.io/?utm_source=watermark&utm_medium=email&utm_campaign=watermark-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 “%define api.token.constructor” directive.

When I get a chance (at the earliest, late next week), I’ll 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 <thomas.evans.shields@icloud.com> 
> wrote:
> 
> Using the glr2.cc <http://glr2.cc/> file that generated the  ‘git diff’ 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 ‘git diff’ 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.
> 
> <glr2.cc.diff>
> 
>> On Sep 2, 2021, at 1:20 PM, Tom Shields <thomas.evans.shields@icloud.com 
>> <mailto:thomas.evans.shields@icloud.com>> wrote:
>> 
>> My Bison GLR application uses multiple parsers linked into a single 
>> executable generated with the same ‘api.namespace' value but with different 
>> ‘api.parser.class' values.
>> 
>> I’m 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 bug-bison@gnu.org <mailto:bug-bison@gnu.org>). 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’t (yet) support '%define 
>> parse.error custom’, so I did a quick&dirty copy&paste to add that missing 
>> feature, based on the existing support for ‘’%define parse.error custom' in 
>> the glr.c skeleton and got duplicated symbol linker errors for the following 
>> symbols:
>> 
>> 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
>> 
>> Adding ‘static’ to 'create_state_set_index' and wrapping the ‘glr_state’ and 
>> ‘semantic_option’ classes in the anonymous namespace eliminates the problems.
>> 
>> Attached is a 'git diff’ of my quick&dirty version of glr2.cc 
>> <http://glr2.cc/>.
>> 
>> As I’m not by any means a C++ expert, and as Akim tells me he is working on 
>> adding support for ‘%define parse.error custom” himself, I don’t 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/>.
>> 
>> Regards,
>> 
>> Tom Shields
>> +1 214-287-9093
>> 
>> <glr2.cc.diff>
>