[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updating a legacy bison/yacc grammar file (HELP!)
From: |
Akim Demaille |
Subject: |
Re: Updating a legacy bison/yacc grammar file (HELP!) |
Date: |
Mon, 15 Jun 2020 06:49:45 +0200 |
Hi Aryeh,
> Le 14 juin 2020 à 17:22, Aryeh Friedman <aryeh.friedman@gmail.com> a écrit :
>
> In attempting to update a previously working (pre-3.6) set of .y's I am now
> getting an error that makes no sense to me (I am not the original author)
> and all attempts to fix it fail.
If you can provide us with a link to the grammar, I might be easier for
us to help you.
> If I do nothing I get the following error in code that was added by bison
> when generating the parser (I can't find any reference to the string
> literals in the .y's I am attempting to update):
>
>
> fmtgen/parse.yacc.cc:1735:19: error: called object type 'parse_tokentype'
> is not a function or function pointer
> parse_error (parse__("syntax error"));
> ~~~~~~~~~~~ ^
> fmtgen/parse.yacc.cc:1846:15: error: called object type 'parse_tokentype'
> is not a function or function pointer
> parse_error (parse__("memory exhausted"));
> ~~~~~~~~~~~ ^
> 2 errors generated.
This is the sign that you have a collision between two names: yyerror
and YYerror. Somehow, somewhere, someone has mapped both YY and yy to
parse_. So both YYerror and yyerror become parse_error.
> If I change the definition of parse_error as follows in lex.h:
>
> #define parse_error yyerror // I have a working yyerror (I think since
> other calls to it work)
That's not the problem.
> I get:
>
> mtgen/parse.yacc.cc:140:5: error: redefinition of 'parse_error'
> parse_error = 256, /* error */
> ^
> ./fmtgen/lex.h:115:21: note: expanded from macro 'parse_error'
> #define parse_error parse_error
> ^
> ./fmtgen/lex.h:48:6: note: previous definition is here
> void parse_error(const char *fmt, ...) ATTR_PRINTF(1, 2);
> ^
> fmtgen/parse.yacc.cc:1333:23: error: comparison between pointer and integer
> ('int' and 'void (*)(const char *, ...)')
> else if (parse_char == parse_error)
> ~~~~~~~~~~ ^ ~~~~~~~~~~~
You should look for the place where the symbols have be renamed. It
might be outside of the grammar itself, in the build system. Have a
look at this bug report, and the answers.
https://lists.gnu.org/r/bug-bison/2020-05/msg00093.html
Cheers!