Re: Updating a legacy bison/yacc grammar file (HELP!)

[Akim Demaille]

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!