search

lexxmark / winflexbison

Main winflexbision repository
GNU General Public License v3.0
414 stars 120 forks source link

Bison 3.3.1 has been released #31

Closed donmac703 closed 5 years ago

donmac703 commented 5 years ago

Bison 3.3.1 has been released. See http://lists.gnu.org/archive/html/bison-announce/2019-01/msg00003.html

it has desirable improvements with respect to C++

lexxmark commented 5 years ago

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

lexxmark commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

lexxmark commented 5 years ago

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

lexxmark commented 5 years ago

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

donmac703 commented 5 years ago

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.