On Solaris, GCC 7.3 defines:
-std=c++14 -std=c++17
__cplusplus 201402L 201703L
__STDC_VERSION__ 199901L 201112L
So the current #definition of _Noreturn sees that 201112 <=
__STDC_VERSION__, i.e., that C11 is supported, so it expects _Noreturn
to be supported. Apparently it is not.
This is only for C++, the test suite works for C. However, the test
suite does not try several C standards, maybe we should...
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00064.html
* data/c.m4 (b4_attribute_define): Define _Noreturn as [[noreturn]] in
modern C++.
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 void
^~~~~~~~~
input.cc:845:8: error: '_Noreturn' does not name a type
static _Noreturn void
^~~~~~~~~
Reported by Kiyoshi Kanazawa.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00051.html
* data/c.m4 (b4_attribute_define): Use the snippet which is currently
in gnulib's m4/gnulib-common.m4 (which seems a little more advanced
than lib/_Noreturn.h).
The "Report translation bugs to..." part of --help is issued only on
glibc systems. So if the tarball is not wrapped on such a system, and
used on such a system (or the converse), then bison.help will differ
on the user's system, and help2man will be called to update bison.1.
But help2man should not be a requirement.
Reported by Alexandre Duret-Lutz.
* doc/local.mk (doc/bison.help): Remove the possible doc about
translation bugs.
Pass LC_ALL=C, as reported in src/getargs.c's usage().
(doc/cross-options.texi): Use bison.help instead of calling bison
--help.
Some users rely on this sentence to know that the file can be ignored.
Reported by Alexandre Duret-Lutz.
* data/bison.m4 (b4_generated_by): New.
(b4_copyright): Use it.
* data/location.cc, data/stack.hh: Use it too, for the stub files
(position.hh and stack.hh).
* doc/bison.texi (Calc++ Scanner): Show how exception can be thrown
from auxiliary functions.
Clarify the meaning of the various flex %options we use.
Get rid of a warning.
(Calc++ Parsing Driver): Use the parser as a functor.
* doc/bison.texi: Simplify wording.
Fix Texinfo error.
(Complete Symbols): Handle the token EOF.
(Calc++ Parser): In the modern C++ world, prefer assignment to swap.
(Strings are Destroyed): Prefer an explicit 'continue' to a comment.
The CI is using Flex 2.5.35. And ICC is too picky for it. Let's stop
making these warnings errors. I wish I could disable them in the
source files using the ICC version and the Flex version, but ICC's
pragma support is unclear, and I'm tired of fighting it.
* configure.ac (FLEX_SCANNER_CXXFLAGS): Make warnings warnings.
* examples/c++/local.mk: Comment changes.
Suggested by Victor Khomenko.
http://lists.gnu.org/archive/html/bug-bison/2018-08/msg00037.html
* doc/bison.texi (A Simple C++ Example): New.
* examples/c++/local.mk, examples/c++/simple.test: New.
Extract, check, and install this new example.
* examples/local.mk: Adjust.
* examples/test: Adjust to the case where the dirname differs
from the test name.
* build-aux/local.mk, cfg.mk, examples/calc++/local.mk,
* examples/local.mk, examples/mfcalc/local.mk,
* examples/rpcalc/local.mk, lib/local.mk, src/local.mk,
* tests/local.mk:
Use Automake comments so that we don't get a copy of each in the
generated Makefile.
On the CI, both GCC and Clang report:
src/parse-gram.c: In function 'yy_lac':
src/parse-gram.c:1479:29: error: format '%hd' expects argument of type 'int',
but argument 3 has type 'yytype_int16 {aka long int}' [-Werror=format=]
YYDPRINTF ((stderr, " G%hd", yystate));
^
Although yytype_int16 is supposed to be a short int, not a long int.
This must be explored.
* data/yacc.c (yy_lac): Work around typing issue.
* data/glr.c: Don't use `foo |= bar` with foo and bar being yybool:
the result appears to be an int, not a yybool.
Use yybool where appropriate.
Add casts where needed.
Reported by Derek Clegg.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00018.html
Rather than adding casts, we should be more careful with types. For
instance yystate should be a yytype_int16. But currently we can't: it
is also used sometimes for storing other things that state numbers.
* data/yacc.c (yyparse): Add missing casts.
The yacc.c skeleton is old, and was using many tricks to save
registers. Today's register allocators can do this themselves. Let's
keep the code simpler to read and let compilers do their job.
* data/yacc.c: Avoid using yystate for different types of content.
An inline function would be better, but doing this portably will be
a problem.
