Re: bison-3.2 released [stable]
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > However, there are build portability issues, 3.2.1 will have to be > soon. Or maybe 3.2.1.0, that’s too tempting. Oh well, that sort of thing happens. > In the past there were skeletons for Python and D circulating, but how > they would be maintained was not clear, and they were never integrated. Would we like to find people to finish those up and contribute them? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: bison-3.2 make fails on Solaris 11.3 x86/64
Hello,
What I did are:
% ./configure --prefix=/opt/local --disable-nls CC=gcc CXX=g++
(GNU softwares are installed on /opt/local)
% make
% make -k check
Also did the same with bison-3.1, because I remember
>> 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332)
was not found with it.
testsuite.log of both are attached.
Regards,
--- Kiyoshi
- Original Message -
> From: Akim Demaille
> To: Kiyoshi KANAZAWA
> Cc: Bison Bugs ; Bison Patches
> Date: 2018/10/31, Wed 03:57
> Subject: Re: bison-3.2 make fails on Solaris 11.3 x86/64
>
>
>
>> Le 30 oct. 2018 à 09:49, Kiyoshi KANAZAWA
> a écrit :
>>
>> Hello,
>>
>> make passed with bison-3.2.3-5d07f.
>>
>> 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332)
>
> This is:
>
>> # -*- compilation -*-
>> 479. c++.at:1293: testing C++ GLR parser identifier shadowing ...
>> ./c++.at:1331: bison -fno-caret -o input.cc input.yy
>> Testing with C++ standard flags: ''
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> stdout:
>> Testing with C++ standard flags: '-std=c++98'
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> stdout:
>> Testing with C++ standard flags: '-std=c++03'
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> stdout:
>> Testing with C++ standard flags: '-std=c++11'
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> stdout:
>> Testing with C++ standard flags: '-std=c++14'
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> stdout:
>> Testing with C++ standard flags: '-std=c++17'
>> ./c++.at:1332: $BISON_CXX_WORKS
>> stderr:
>> stdout:
>> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
>> stderr:
>> input.cc:837:8: error: '_Noreturn' does not name a type
>> static _Noreturn void
>> ^
>> input.cc:845:8: error: '_Noreturn' does not name a type
>> static _Noreturn void
>> ^
>> input.cc: In function 'void yyexpandGLRStack(yyGLRStack*)':
>> input.cc:1226:5: error: 'yyMemoryExhausted' was not declared in
> this scope
>> yyMemoryExhausted (yystackp);
>> ^
>> input.cc:1232:5: error: 'yyMemoryExhausted' was not declared in
> this scope
>> yyMemoryExhausted (yystackp);
>> ^
>> input.cc: In function 'std::size_t yysplitStack(yyGLRStack*,
> std::size_t)':
>> input.cc:1568:9: error: 'yyMemoryExhausted' was not declared in
> this scope
>> yyMemoryExhausted (yystackp);
>> ^
>> input.cc:1576:9: error: 'yyMemoryExhausted' was not declared in
> this scope
>> yyMemoryExhausted (yystackp);
>> ^
>> input.cc:1584:9: error: 'yyMemoryExhausted' was not declared in
> this scope
>> yyMemoryExhausted (yystackp);
>> ^
>> input.cc: In function 'void yyrecoverSyntaxError(yyGLRStack*,
> yy::parser&)':
>> input.cc:2225:11: error: 'yyFail' was not declared in this scope
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> input.cc:2225:11: note: suggested alternative: 'yyfill'
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> yyfill
>> input.cc:2262:5: error: 'yyFail' was not declared in this scope
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> input.cc:2262:5: note: suggested alternative: 'yyfill'
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> yyfill
>> input.cc:2296:5: error: 'yyFail' was not declared in this scope
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> input.cc:2296:5: note: suggested alternative: 'yyfill'
>> yyFail (yystackp, yyparser, YY_NULLPTR);
>> ^~
>> yyfill
>> input.cc: In function 'int yyparse(yy::parser&)':
>> input.cc:2446:17: error: 'yyFail' was not declared in this scope
>> yyFail (, yyparser, YY_("syntax
> error"));
>> ^~
>> input.cc:2446:17: note: suggested alternative: 'yyfill'
>> yyFail (, yyparser, YY_("syntax
> error"));
>> ^~
>> yyfill
>> stdout:
>> ./c++.at:1332: exit code was 1, expected 0
>> 479. c++.at:1293: 479. C++ GLR parser identifier shadowing (c++.at:1293):
> FAILED (c++.at:1332)
>
>
> So I propose the patch below. Here, the real testsuite.log would probably
Re: bison-3.2 make fails on Solaris 11.3 x86/64
Hi,
I should have told you about the locale.
Very limited locale is installed on my system:
% locale -a
C
POSIX
en_US.ISO8859-1
en_US.ISO8859-15
en_US.ISO8859-15@euro
en_US.UTF-8
ja_JP.PCK
ja_JP.UTF-8
ja_JP.UTF-8@cldr
ja_JP.eucJP
So, I usually use
% ./configure --disable-nls
Will check again after reading another email from you.
--- Kiyoshi
- Original Message -
> From: Akim Demaille
> To: Kiyoshi KANAZAWA
> Cc: Bison Bugs ; Bison Patches
> Date: 2018/10/31, Wed 03:51
> Subject: Re: bison-3.2 make fails on Solaris 11.3 x86/64
>
> Hi!
>
>> Le 30 oct. 2018 à 09:49, Kiyoshi KANAZAWA
> a écrit :
>>
>> Hello,
>>
>> make passed with bison-3.2.3-5d07f.
>>
>> But, make check fails as
>> FAIL: examples/calc++/calc++.test
>> 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332)
>>
>>
>> calc++.log & 479/testsuite.log are attached.
>
> Please, next time send tests/testsuite.log, like the final message of
> the testsuite asks. It will save mails exchanges to get details
> about your environment.
>
> Your calc++.log contains:
>
> ./examples/test[97]: .[64]: local: not found [No such file or directory]
> ./examples/test[97]: .[70]: local: not found [No such file or directory]
> ./examples/test[97]: .[73]: local: not found [No such file or directory]
> ./examples/test[97]: .[76]: local: not found [No such file or directory]
> ./examples/test[97]: .[79]: local: not found [No such file or directory]
> calc++: PASS: 1
>
> so I will install this:
>
> commit ca8039e61279fcb1d15ae5333ef9007db85fd870
> Author: Akim Demaille
> Date: Tue Oct 30 19:04:31 2018 +0100
>
> tests: don't expect the shell to support 'local'
>
> It doesn't work on Solaris 11.3 x86/64.
> Reported by Kiyoshi Kanazawa.
> http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00051.html
>
> * examples/test: Don't use 'local'.
>
> diff --git a/examples/test b/examples/test
> index 251307b0..96db4e7f 100755
> --- a/examples/test
> +++ b/examples/test
> @@ -45,7 +45,7 @@ fi
> # ---
> cleanup ()
> {
> - local status=$?
> + status=$?
> if test -z "$DEBUG"; then
> cd $cwd
> rm -rf $$.dir
> @@ -61,22 +61,22 @@ cd $$.dir
> # -noerr: ignore stderr, otherwise merge it into effective output.
> run ()
> {
> - local noerr=false
> + noerr=false
> case $1 in
> (-noerr) noerr=true; shift;;
> esac
>
> # Expected exit status.
> - local sta_exp="$1"
> + sta_exp=$1
> shift
> # Expected output.
> - local out_exp="$1"
> + out_exp=$1
> shift
> # Effective exit status.
> - local sta_eff=0
> + sta_eff=0
> $prog "$@" - out_eff 2>err_eff || sta_eff=$?
> # Combine effective output and error streams.
> - local out_eff="$(cat out_eff && $noerr || sed -e 's/^/err:
> /g' err_eff)"
> + out_eff=$(cat out_eff && $noerr || sed -e 's/^/err: /g'
> err_eff)
> if test $sta_eff -eq $sta_exp; then
> if test "$out_eff" = "$out_exp"; then
> echo "$me: PASS: $number"
>
Re: bison-3.2 build feedback
Hi Nelson! You, running the Bison test suite, is a wonderful news! Thanks _a whole lot_ for this. > Le 30 oct. 2018 à 21:14, Nelson H. F. Beebe a écrit : > > I've just done test builds of bison-3.2 with CC=cc in our > test farm: 204 builds, of which 77 passed their tests. > > There are, however, 92 systems that fail like this: > > CC lib/xmemdup0.o > AR lib/libbison.a > > ar: -lm: No such file or directory > or > ar: fatal: Can't specify both -m and -r > or > ar: -lrt: No such file or directory > or > ar: two different operation options specified I’m very sorry about this. I have already fixed this here: https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00151.html and a few more issues. You should try this tarball instead: https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.5-bd7ae.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.5-bd7ae.tar.xz Cheers!
bison-3.2 build feedback
I've just done test builds of bison-3.2 with CC=cc in our test farm: 204 builds, of which 77 passed their tests. There are, however, 92 systems that fail like this: CC lib/xmemdup0.o AR lib/libbison.a ar: -lm: No such file or directory or ar: fatal: Can't specify both -m and -r or ar: -lrt: No such file or directory or ar: two different operation options specified The failures include whole families on operating systems, such as almost all *BSD* family members. On one of those failing builds, on CentOS 6, I tried a manual build: % set path=( /bin /usr/bin ) % unsetenv CONFIG_SITE % ./configure --prefix=/usr/local && make all check % make LIB_CLOCK_GETTIME= LIB_GETHRXTIME= % make LIB_CLOCK_GETTIME= LIB_GETHRXTIME= LIBS=-lrt % make check ... ## - ## ## Test results. ## ## - ## ERROR: 527 tests were run, 14 failed unexpectedly. 2 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: Subject: [GNU Bison 3.2] testsuite: 163 481 482 483 484 485 \ 486 487 488 496 497 498 499 500 failed By contrast, on CentOS 7, the build and test completed like this: ## - ## ## Test results. ## ## - ## 527 tests were successful. 2 tests were skipped. Before we worry about test failures, I'd first like to resolve the numerous failures of ar for building libbison.a. The complexification introduced by automake makes my head spin when I try to figure out where things are going wrong, but perhaps you folks can do so. Any BSD or Solaris system should do for testing this aspect of builds of bison-3.2. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: bison-3.2 make fails on Solaris 11.3 x86/64
> Le 30 oct. 2018 à 09:49, Kiyoshi KANAZAWA a
> écrit :
>
> Hello,
>
> make passed with bison-3.2.3-5d07f.
>
> 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332)
This is:
> # -*- compilation -*-
> 479. c++.at:1293: testing C++ GLR parser identifier shadowing ...
> ./c++.at:1331: bison -fno-caret -o input.cc input.yy
> Testing with C++ standard flags: ''
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> stdout:
> Testing with C++ standard flags: '-std=c++98'
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> stdout:
> Testing with C++ standard flags: '-std=c++03'
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> stdout:
> Testing with C++ standard flags: '-std=c++11'
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> stdout:
> Testing with C++ standard flags: '-std=c++14'
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> stdout:
> Testing with C++ standard flags: '-std=c++17'
> ./c++.at:1332: $BISON_CXX_WORKS
> stderr:
> stdout:
> ./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc $LIBS
> stderr:
> input.cc:837:8: error: '_Noreturn' does not name a type
> static _Noreturn void
> ^
> input.cc:845:8: error: '_Noreturn' does not name a type
> static _Noreturn void
> ^
> input.cc: In function 'void yyexpandGLRStack(yyGLRStack*)':
> input.cc:1226:5: error: 'yyMemoryExhausted' was not declared in this scope
> yyMemoryExhausted (yystackp);
> ^
> input.cc:1232:5: error: 'yyMemoryExhausted' was not declared in this scope
> yyMemoryExhausted (yystackp);
> ^
> input.cc: In function 'std::size_t yysplitStack(yyGLRStack*, std::size_t)':
> input.cc:1568:9: error: 'yyMemoryExhausted' was not declared in this scope
> yyMemoryExhausted (yystackp);
> ^
> input.cc:1576:9: error: 'yyMemoryExhausted' was not declared in this scope
> yyMemoryExhausted (yystackp);
> ^
> input.cc:1584:9: error: 'yyMemoryExhausted' was not declared in this scope
> yyMemoryExhausted (yystackp);
> ^
> input.cc: In function 'void yyrecoverSyntaxError(yyGLRStack*, yy::parser&)':
> input.cc:2225:11: error: 'yyFail' was not declared in this scope
>yyFail (yystackp, yyparser, YY_NULLPTR);
>^~
> input.cc:2225:11: note: suggested alternative: 'yyfill'
>yyFail (yystackp, yyparser, YY_NULLPTR);
>^~
>yyfill
> input.cc:2262:5: error: 'yyFail' was not declared in this scope
> yyFail (yystackp, yyparser, YY_NULLPTR);
> ^~
> input.cc:2262:5: note: suggested alternative: 'yyfill'
> yyFail (yystackp, yyparser, YY_NULLPTR);
> ^~
> yyfill
> input.cc:2296:5: error: 'yyFail' was not declared in this scope
> yyFail (yystackp, yyparser, YY_NULLPTR);
> ^~
> input.cc:2296:5: note: suggested alternative: 'yyfill'
> yyFail (yystackp, yyparser, YY_NULLPTR);
> ^~
> yyfill
> input.cc: In function 'int yyparse(yy::parser&)':
> input.cc:2446:17: error: 'yyFail' was not declared in this scope
> yyFail (, yyparser, YY_("syntax error"));
> ^~
> input.cc:2446:17: note: suggested alternative: 'yyfill'
> yyFail (, yyparser, YY_("syntax error"));
> ^~
> yyfill
> stdout:
> ./c++.at:1332: exit code was 1, expected 0
> 479. c++.at:1293: 479. C++ GLR parser identifier shadowing (c++.at:1293):
> FAILED (c++.at:1332)
So I propose the patch below. Here, the real testsuite.log would probably
have been useful.
Please report the result on this tarball:
https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.5-bd7ae.tar.gz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.5-bd7ae.tar.xz
Thanks in advance.
commit bd7aebb8b002f0706bfa771f22c01f243fa7fbcf
Author: Akim Demaille
Date: Tue Oct 30 19:09:46 2018 +0100
c: update the definition of _Noreturn
Does not work on Solaris 11.3 x86/64:
479. c++.at:1293: testing C++ GLR parser identifier shadowing ...
Testing with C++ standard flags: '-std=c++17'
./c++.at:1332: $BISON_CXX_WORKS
stderr:
stdout:
./c++.at:1332: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o input input.cc
$LIBS
stderr:
input.cc:837:8: error: '_Noreturn' does not name a type
static _Noreturn
Re: bison-3.2 make fails on Solaris 11.3 x86/64
Hi!
> Le 30 oct. 2018 à 09:49, Kiyoshi KANAZAWA a
> écrit :
>
> Hello,
>
> make passed with bison-3.2.3-5d07f.
>
> But, make check fails as
> FAIL: examples/calc++/calc++.test
> 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332)
>
>
> calc++.log & 479/testsuite.log are attached.
Please, next time send tests/testsuite.log, like the final message of
the testsuite asks. It will save mails exchanges to get details
about your environment.
Your calc++.log contains:
./examples/test[97]: .[64]: local: not found [No such file or directory]
./examples/test[97]: .[70]: local: not found [No such file or directory]
./examples/test[97]: .[73]: local: not found [No such file or directory]
./examples/test[97]: .[76]: local: not found [No such file or directory]
./examples/test[97]: .[79]: local: not found [No such file or directory]
calc++: PASS: 1
so I will install this:
commit ca8039e61279fcb1d15ae5333ef9007db85fd870
Author: Akim Demaille
Date: Tue Oct 30 19:04:31 2018 +0100
tests: don't expect the shell to support 'local'
It doesn't work on Solaris 11.3 x86/64.
Reported by Kiyoshi Kanazawa.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00051.html
* examples/test: Don't use 'local'.
diff --git a/examples/test b/examples/test
index 251307b0..96db4e7f 100755
--- a/examples/test
+++ b/examples/test
@@ -45,7 +45,7 @@ fi
# ---
cleanup ()
{
- local status=$?
+ status=$?
if test -z "$DEBUG"; then
cd $cwd
rm -rf $$.dir
@@ -61,22 +61,22 @@ cd $$.dir
# -noerr: ignore stderr, otherwise merge it into effective output.
run ()
{
- local noerr=false
+ noerr=false
case $1 in
(-noerr) noerr=true; shift;;
esac
# Expected exit status.
- local sta_exp="$1"
+ sta_exp=$1
shift
# Expected output.
- local out_exp="$1"
+ out_exp=$1
shift
# Effective exit status.
- local sta_eff=0
+ sta_eff=0
$prog "$@" - out_eff 2>err_eff || sta_eff=$?
# Combine effective output and error streams.
- local out_eff="$(cat out_eff && $noerr || sed -e 's/^/err: /g' err_eff)"
+ out_eff=$(cat out_eff && $noerr || sed -e 's/^/err: /g' err_eff)
if test $sta_eff -eq $sta_exp; then
if test "$out_eff" = "$out_exp"; then
echo "$me: PASS: $number"
Re: bison-3.2 released [stable]
Hi Richard! > Le 30 oct. 2018 à 03:48, Richard Stallman a écrit : > > Congratulations on the new release. Thanks a lot! However, there are build portability issues, 3.2.1 will have to be soon. Or maybe 3.2.1.0, that’s too tempting. > What other languages does Bison support, currently? Its languages are C, C++, and Java. Some features, unfortunately, are not available in all of them (e.g., C++ does not have push parsers, Java does not have GLR, etc.). > What other languages would it be useful for Bison to support? In the past there were skeletons for Python and D circulating, but how they would be maintained was not clear, and they were never integrated. C++ and Java were added when they were contributed. If there are nice contributions, we could accept more. But there’s already quite a lot to do with the existing skeletons, I’m not eagerly looking for more work :)
Re: Enhancement request: enabling Variant in C parsers
Hi Victor, I agree with Akim, that currently we need to maintain bison’s current design to support all the use cases it support. There was an attempt I created a while ago to generate AST representation in XML out of bison parsing. If what you are looking for is to simplify the way the ASTs are handled, it might be worthy to take a look and see if it fits your purposes and could separate the concerns. ``` git clone https://git.savannah.gnu.org/git/bison.git git pull origin yaxx ``` The branch is slightly outdated, I will test it again if you experience any problems. Best regards, Yijun On 30 Oct 2018, at 10:10, Victor Khomenko mailto:victor.khome...@newcastle.ac.uk>> wrote: Hi Akim, Re flex/bison, ANTLR, and racing cars: I think bison has a number of cool features, in particular nice error handling, support for full LR(1), and glr. They definitely give it an edge over other parser generators. Where it fails: Mundane things like clunky interface with a scanner, too many includes - so too many build dependencies. The latter is partially related to the scanner interface, e.g. if the scanner were integrated, there would be no need to generate parser.h in many cases, i.e. one could manage with a single generated file parser.c[pp]. It would be nice to have some stats about how parser generators (not just bison) are used (maybe you have it). My speculation is that it's mostly *not* about programming languages. Most of my parsers are for simple expressions (every now and then there is some legacy pre-XML format that is mostly regular but has fields containing expressions). In such use-cases, the mundane things prevail and people will increasingly choose e.g. ANTLR for new projects. Ok, maybe they would still choose bison for racing cars (i.e. programming languages). I'm not sure what are the future plans for bison, but I hope it has not quite reached that stage when one declares that it has done its service to the community and it's time to retire and give way to the younger generation... So I'd still consider the possibility of integrating a scanner generator into bison, maybe a severely cut-down version of flex, without any fancies like REJECT, etc. Essentially, it should be possible to build an equivalent of calc++ with only calc++.y and generated calc++.cpp, without any other files. I'd vote for this as the most desirable feature. I realise it's much work, but I believe without this bison will eventually lose to ANTRL. Cheers, Victor. -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority in relation to its secondary activity of credit broking.
Re: bison-3.2 released [stable]
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Congratulations on the new release. What other languages does Bison support, currently? What other languages would it be useful for Bison to support? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
RE: Enhancement request: enabling Variant in C parsers
Hi Akim, Re flex/bison, ANTLR, and racing cars: I think bison has a number of cool features, in particular nice error handling, support for full LR(1), and glr. They definitely give it an edge over other parser generators. Where it fails: Mundane things like clunky interface with a scanner, too many includes - so too many build dependencies. The latter is partially related to the scanner interface, e.g. if the scanner were integrated, there would be no need to generate parser.h in many cases, i.e. one could manage with a single generated file parser.c[pp]. It would be nice to have some stats about how parser generators (not just bison) are used (maybe you have it). My speculation is that it's mostly *not* about programming languages. Most of my parsers are for simple expressions (every now and then there is some legacy pre-XML format that is mostly regular but has fields containing expressions). In such use-cases, the mundane things prevail and people will increasingly choose e.g. ANTLR for new projects. Ok, maybe they would still choose bison for racing cars (i.e. programming languages). I'm not sure what are the future plans for bison, but I hope it has not quite reached that stage when one declares that it has done its service to the community and it's time to retire and give way to the younger generation... So I'd still consider the possibility of integrating a scanner generator into bison, maybe a severely cut-down version of flex, without any fancies like REJECT, etc. Essentially, it should be possible to build an equivalent of calc++ with only calc++.y and generated calc++.cpp, without any other files. I'd vote for this as the most desirable feature. I realise it's much work, but I believe without this bison will eventually lose to ANTRL. Cheers, Victor.
Re: bison-3.2 make fails on Solaris 11.3 x86/64
Hello, make passed with bison-3.2.3-5d07f. But, make check fails as FAIL: examples/calc++/calc++.test 479: C++ GLR parser identifier shadowing FAILED (c++.at:1332) calc++.log & 479/testsuite.log are attached. Regards, --- Kiyoshi - Original Message - > From: Akim Demaille > To: Kiyoshi KANAZAWA > Cc: Bison Bugs ; Bison Patches > Date: 2018/10/30, Tue 15:31 > Subject: Re: bison-3.2 make fails on Solaris 11.3 x86/64 > > > >> Le 30 oct. 2018 à 02:25, Kiyoshi KANAZAWA > a écrit : >> >> Hello, >> Trying to build bison-3.2 on Solaris 11.3 x86/64, but failed. >> >> % uname -a >> SunOS 5.11 11.3 i86pc i386 i86pc >> >> % gcc --version >> gcc (GCC) 7.3.0 >> % ar --version >> GNU ar (GNU Binutils) 2.31.1 >> >> >> >> % ./configure CC=gcc >> % make >> : >> CC lib/vsprintf.o >> CC lib/xmemdup0.o >> AR lib/libbison.a > > Bummer… > > I have installed the following patch. Could you please try this tarball? > Thanks in advance. > > https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.3-5d07f.tar.gz > https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.3-5d07f.tar.xz > > > commit e605ad9679b583bf7e09afe00daf23e0dfa6c823 > Author: Akim Demaille > Date: Tue Oct 30 06:55:47 2018 +0100 > > build: fix use of gnulib Make variables > > Reported by Kiyoshi Kanazawa. > http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00048.html > > * lib/local.mk (lib_libbison_a_LIBADD): Merge into... > * src/local.mk (src_bison_LDADD): here. > > diff --git a/THANKS b/THANKS > index 3437e808..7254bb3f 100644 > --- a/THANKS > +++ b/THANKS > @@ -84,6 +84,7 @@ Juan Manuel Guerrero juan.guerr...@gmx.de > Kees Zeelenberg k...@users.sourceforge.net > Keith Browne kbro...@legato.com > Ken Moffat zarniwh...@ntlworld.com > +Kiyoshi Kanazawa yoi_no_myou...@yahoo.co.jp > Laurent Mascherpa laurent.masche...@epita.fr > Lie Yan lie@kaust.edu.sa > Magnus Fromreide ma...@lysator.liu.se > diff --git a/lib/local.mk b/lib/local.mk > index aec635a8..18c0953d 100644 > --- a/lib/local.mk > +++ b/lib/local.mk > @@ -45,15 +45,6 @@ lib_libbison_a_SOURCES += \ > lib/path-join.h \ > lib/path-join.c > > -lib_libbison_a_LIBADD += \ > - $(ISNAND_LIBM) \ > - $(ISNANF_LIBM) \ > - $(ISNANL_LIBM) \ > - $(LDEXPL_LIBM) \ > - $(LDEXP_LIBM) \ > - $(LIB_CLOCK_GETTIME) \ > - $(LIB_GETHRXTIME) > - > # The Yacc compatibility library. > if ENABLE_YACC > lib_LIBRARIES = lib/liby.a > diff --git a/src/local.mk b/src/local.mk > index 0651aac1..6d5adfd9 100644 > --- a/src/local.mk > +++ b/src/local.mk > @@ -104,9 +104,19 @@ BUILT_SOURCES += \ > src/scan-gram.c \ > src/scan-skel.c > > +# Although conceptually most of these guys would make more sense in the > +# definition of libbison, beware that they might expand as flags such as > +# `-lm`. Keep them here. Or use a Libtool convenience library. > src_bison_LDADD = \ > + $(ISNAND_LIBM) \ > + $(ISNANF_LIBM) \ > + $(ISNANL_LIBM) \ > + $(LDEXPL_LIBM) \ > + $(LDEXP_LIBM) \ > $(LIBINTL) \ > $(LIBTHREAD) \ > + $(LIB_CLOCK_GETTIME) \ > + $(LIB_GETHRXTIME) \ > lib/libbison.a > calc++.log.xz Description: Binary data 479_testsuite.log.xz Description: Binary data
Re: bison-3.2 make fails on Solaris 11.3 x86/64
> Le 30 oct. 2018 à 02:25, Kiyoshi KANAZAWA a > écrit : > > Hello, > Trying to build bison-3.2 on Solaris 11.3 x86/64, but failed. > > % uname -a > SunOS 5.11 11.3 i86pc i386 i86pc > > % gcc --version > gcc (GCC) 7.3.0 > % ar --version > GNU ar (GNU Binutils) 2.31.1 > > > > % ./configure CC=gcc > % make > : > CC lib/vsprintf.o > CC lib/xmemdup0.o > AR lib/libbison.a Bummer… I have installed the following patch. Could you please try this tarball? Thanks in advance. https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.3-5d07f.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.2.3-5d07f.tar.xz commit e605ad9679b583bf7e09afe00daf23e0dfa6c823 Author: Akim Demaille Date: Tue Oct 30 06:55:47 2018 +0100 build: fix use of gnulib Make variables Reported by Kiyoshi Kanazawa. http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00048.html * lib/local.mk (lib_libbison_a_LIBADD): Merge into... * src/local.mk (src_bison_LDADD): here. diff --git a/THANKS b/THANKS index 3437e808..7254bb3f 100644 --- a/THANKS +++ b/THANKS @@ -84,6 +84,7 @@ Juan Manuel Guerrero juan.guerr...@gmx.de Kees Zeelenberg k...@users.sourceforge.net Keith Browne kbro...@legato.com Ken Moffatzarniwh...@ntlworld.com +Kiyoshi Kanazawa yoi_no_myou...@yahoo.co.jp Laurent Mascherpa laurent.masche...@epita.fr Lie Yan lie@kaust.edu.sa Magnus Fromreide ma...@lysator.liu.se diff --git a/lib/local.mk b/lib/local.mk index aec635a8..18c0953d 100644 --- a/lib/local.mk +++ b/lib/local.mk @@ -45,15 +45,6 @@ lib_libbison_a_SOURCES += \ lib/path-join.h \ lib/path-join.c -lib_libbison_a_LIBADD +=\ - $(ISNAND_LIBM)\ - $(ISNANF_LIBM)\ - $(ISNANL_LIBM)\ - $(LDEXPL_LIBM)\ - $(LDEXP_LIBM) \ - $(LIB_CLOCK_GETTIME) \ - $(LIB_GETHRXTIME) - # The Yacc compatibility library. if ENABLE_YACC lib_LIBRARIES = lib/liby.a diff --git a/src/local.mk b/src/local.mk index 0651aac1..6d5adfd9 100644 --- a/src/local.mk +++ b/src/local.mk @@ -104,9 +104,19 @@ BUILT_SOURCES +=\ src/scan-gram.c \ src/scan-skel.c +# Although conceptually most of these guys would make more sense in the +# definition of libbison, beware that they might expand as flags such as +# `-lm`. Keep them here. Or use a Libtool convenience library. src_bison_LDADD = \ + $(ISNAND_LIBM)\ + $(ISNANF_LIBM)\ + $(ISNANL_LIBM)\ + $(LDEXPL_LIBM)\ + $(LDEXP_LIBM) \ $(LIBINTL)\ $(LIBTHREAD) \ + $(LIB_CLOCK_GETTIME) \ + $(LIB_GETHRXTIME) \ lib/libbison.a
Re: bison-3.2 released [stable]
> Le 29 oct. 2018 à 22:52, Hans Åberg a écrit :
>
>
>> On 29 Oct 2018, at 21:33, Akim Demaille wrote:
>>
>> We are very happy to announce the release of Bison 3.2!
>
> Actually two warnings on make with MacOS inhouse clang, the obstack one same
> as with 3.1 :-), and one with the bitset. All tests passed though.
Thanks, I installed this.
commit 5d07f4f726de562778ab358d4bdf4fe8bae517bb
Author: Akim Demaille
Date: Tue Oct 30 07:00:34 2018 +0100
bitset: fix warning
Reported by Hans Åberg.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00047.html
* lib/bitset.c (bitset_count_): here.
diff --git a/lib/bitset.c b/lib/bitset.c
index f8249b8c..32521377 100644
--- a/lib/bitset.c
+++ b/lib/bitset.c
@@ -353,7 +353,7 @@ bitset_count_ (bitset src)
{
bitset_bindex next = 0;
bitset_bindex num;
-while (num = bitset_list (src, list, BITSET_LIST_SIZE, ))
+while ((num = bitset_list (src, list, BITSET_LIST_SIZE, )))
count += num;
}
