Bison 3.3.1 has been released about winflexbison

[lexxmark]

It takes longer time than I expected. Some major refactorings in timevar.c code.
Work in progress...

[lexxmark]

I managed to successfully build bison code version 3.3.1 (see bison3.3.1 branch)
Unfortunately it doesn't work on simple *.y files.
I'm going to debug it.

[lexxmark]

I have fixed problems with string concatenations in win_bison.

@donmac703 please check the package win_flex_bison-3.3.1.zip

In the bison3.3.1 branch I've updated CMake project and VS2017 project files.
@GitMensch Please update VS2015 and VS2013 if you have access to such versions of Visual Studio.
There are some compile errors in VS2013 (see https://ci.appveyor.com/project/lexxmark/winflexbison/builds/22161281). We should decide if we want to fix it or just drop VS2013 support.

[donmac703]

Hi Alex, Apologies for the delay in responding.

The code package you provided appears to produce the expected results against my current source base. I have not tested any new Bison features yet (so cannot vouch for them), but have compiled against the features I was previously using. I think that most users would find that using some of the new features has ripple effects through the code that are sometimes non-trivial so we would need to trust the upstream source at this point-in-time.
Currently, I am using the Visual Studio 2019 Preview (with /std:c++latest) on this particular source base, so there are a number of moving parts from my perspective.

[lexxmark]

OK.
I hope next bison releases will have minor changes and thus easy to adopt.
I'll prepare a new winflexbison version and publish it soon.

[donmac703]

Hi Alex,
Upon further review I have discovered that running win_bison against the example maintained by Akim (https://github.com/akimd/bison/blob/master/examples/c%2B%2B/variant.yy) that it emits lines such as:

#line 69 "test.y" // lalr1.cc:435
and
#line 115 "test.tab.cpp" // lalr1.cc:435

Actual command line used is:

start /B /WAIT /D "E:\myfolder" win_bison.exe --output="test.tab.cpp" --defines="test.tab.h" "test.y"
exit /b %errorlevel%

Not sure why the second one does not have the source file name (test.y). Not sure if it is an upstream problem...

[lexxmark]

Hi DonMac,

I think it's expected behavior.
In the code like:

      case 7: // list
#line 73 "variant.yy" // lalr1.cc:676
        { yyo << '(' << &yysym.value.template as < ::std::vector<std::string> > () << ") " << yysym.value.template as < ::std::vector<std::string> > (); }
#line 364 "test.tab.cpp" // lalr1.cc:676
        break;

      case 8: // item
#line 73 "variant.yy" // lalr1.cc:676
        { yyo << '(' << &yysym.value.template as < ::std::string > () << ") " << yysym.value.template as < ::std::string > (); }
#line 370 "test.tab.cpp" // lalr1.cc:676
        break;

The line

#line 73 "variant.yy" // lalr1.cc:676

refers to the code from variant.yy and

#line 370 "test.tab.cpp" // lalr1.cc:676

returns to the generated code in test.tab.cpp because there is no such code in variant.yy

What do you think?

[GitMensch]

Yes, that's the rule and the generation of two different file names the correct thing to do.

[lexxmark]

OK, if there is no more complains I'm going to release it in a couple of days.

[lexxmark]

@donmac703 please check released package and close issue if it's OK.

[donmac703]

Hi Alex,
I have downloaded and installed the package.
My query about behavior was to determine expectations.
The consensus is that we are getting the correct behavior, and I am getting the expected IDE behavior when the error occurs in the code fragment in the bison source file. (Have not tested step-by-step debugging yet)
Thanks for working on this and making the new features available for use. I am closing this issue.