bison-patches
[Top][All Lists]
Advanced

[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: Thu, 2 Sep 2021 16:27:10 -0500

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.



         
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

> On Sep 2, 2021, at 1:20 PM, Tom Shields <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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]