bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOF redefinition (3.5->3.6 error)


From: Akim Demaille
Subject: Re: EOF redefinition (3.5->3.6 error)
Date: Mon, 15 Jun 2020 07:43:50 +0200

Hi Egor,

> Le 14 juin 2020 à 17:17, Egor Pugin <egor.pugin@gmail.com> a écrit :
> 
> Now it says different error: error: unknown type name 'YY_RANGESTYPE'
> https://pastebin.com/fknMpDah

I believe the problem is that you depend on YYSTYPE, and you should not.
It exists in C, but in C++ you should use yy::parser::semantic_type.
The only reason you could use it before, is because it "leaked" from
glr.cc to glr.c.  yy::parser::semantic_type exists since the beginning.

So in

https://github.com/egorpugin/primitives/blob/0d917974163e2fd84f952050f3e046445a8c162a/src/templates/include/primitives/helper/bison.h#L346

instead of

#define MY_LEXER_FUNCTION_SIGNATURE_BODY lex(PARSER_NAME_UP(STYPE) * val, 
THIS_PARSER2::location_type * loc)

you should have

#define MY_LEXER_FUNCTION_SIGNATURE_BODY lex(THIS_PARSER2::semantic_type * val, 
THIS_PARSER2::location_type * loc)


> Also what about adding BISON_VERSION macro to the generated
> header/source as I proposed in the previous message?

So far, I don't see a need for this.  We have had that in C from the start, so 
I kept it, but there's nothing equivalent to be done in D and Java, and so far, 
in C++, it does not appears to be required.

For instance in the present case, the fact that it does not exist allowed me to 
spot a problem in your bison.y, instead of adding incorrect workarounds.

Please, confirm that once this issue fixed, the tarball I sent you fixes all 
your problems.

Cheers!

        Akim


reply via email to

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