[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with the new bison glr2.cc skeleton in the Savannah Git rep
From: |
Tom Shields |
Subject: |
Re: Problems with the new bison glr2.cc skeleton in the Savannah Git repository |
Date: |
Wed, 8 Sep 2021 13:56:51 -0500 |
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>
>