[Debian-med-packaging] bison/flex (?) issue: error: cannot convert 'UserLevelRewritingContext::ParseResult*' to 'char*'

[Andreas Tille]

Hi Sergio

On Wed, Sep 19, 2018 at 12:50:37AM -0400, Sergio Durigan Junior wrote:
> On Sunday, September 16 2018, Andreas Tille wrote:
> 
> > Hi,
> >
> > in the latest version of maude[1] I get:
> >
> > ...
> > g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal -I../../src/Interface -I../../src/Core -I../../src/Variable -I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory -I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory -I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn -I../../src/MSCP10 -I../../src/IO_Stuff -I../../src/ACU_Persistent -I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory -I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler -I../../src/StrategyLanguage -I../../src/SMT -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/build/maude-2.7.1=. -fstack-protector-strong -Wformat -Werror=format-security -fpermissive -c -o libmixfix_a-surface.o `test -f 'surface.cc' || echo './'`surface.cc
> > surface.c: In function 'int yyparse(void*, UserLevelRewritingContext::ParseResult*)':
> > surface.c:5382:16: warning: invalid conversion from 'void*' to 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5382:31: error: cannot convert 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char *s);
> >                                                                           ~~~~~~^
> > surface.c:5526:12: warning: invalid conversion from 'void*' to 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5526:27: error: cannot convert 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char *s);
> >                                                                           ~~~~~~^
> > surface.yy:313:12: warning: ignoring return value of 'int system(const char*)', declared with attribute warn_unused_result [-Wunused-result]
> >       system((string("ls") + $3).c_str());
> >       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                
> > make[6]: *** [Makefile:1110: libmixfix_a-surface.o] Error 1
> > ...
> >
> > I suspect bison/flex might have created a broken C++ file.  Any idea how
> > to fix this?
> 
> Hey Andreas,
> 
> Short:
> 
> Yeah, if you remove debian/patches/bison-parse-param.patch, it compiles
> successfully.

Cool.  I can confirm this and pushed the change to Git.
 
> Long:
> 
> I haven't investigated a lot, but apparently the parser used
> YYPARSE_PARAM to define 'UserLevelRewritingContext::ParseResult*' as a
> possible argument for the reentrant parser.  However, at some point the
> code was rewritten to explicitly use and pass
> 'UserLevelRewritingContext::ParseResult*', without resorting to
> YYPARSE_PARAM.  For that reason, there's no need to define "%parse-param
> {void* YYPARSE_PARAM}" in the beginning of the parser code anymore.
 
Thanks a lot for the detailed explanation.

> Now, after this fix, I'm seeing another error:
> 
>   variableGenerator.cc: In member function 'CVC4::Expr VariableGenerator::dagToCVC4(DagNode*)':
>   variableGenerator.cc:326:73: error: 'IFF' is not a member of 'CVC4::kind'
>         return exprManager->mkExpr(((smtType == SMT_Info::BOOLEAN) ? kind::IFF : kind::EQUAL), exprs[0], exprs[1]);
>                                                                            ^~~
> 
> CVC4 indeed doesn't have any 'kind::IFF'.  I spent some time looking at
> its source code, but couldn't find anything helpful.  I can try to work
> more later.

I admit I also have no clue.

@Scott: You initially worked on this package.  Will you continue with
this and may be you have some clue about the issue above?

Kind regards

     Andreas.

-- 
http://fam-tille.de