I’m seeing a minor warning when building bison-3.1.91:
lib/obstack.c:351:31: warning: incompatible pointer types initializing 'void
(*)(void) __attribute__((noreturn))' with an expression of type
'void (void)' [-Wincompatible-pointer-types]
__attribute_noreturn__ void (*obstack_alloc_failed_handler) (void)
Patch:
diff -ur bison-3.1.91/lib/obstack.c bison/lib/obstack.c
--- bison-3.1.91/lib/obstack.c 2018-09-02 09:08:33.000000000 -0700
+++ bison/lib/obstack.c 2018-10-21 10:36:46.000000000 -0700
@@ -326,7 +326,7 @@
# include <libio/iolibio.h>
# endif
-static _Noreturn void
+static __attribute_noreturn__ void
print_and_abort (void)
{
/* Don't change any of these strings. Yes, it would be possible to add
Derek Clegg
> On Oct 18, 2018, at 4:44 AM, Akim Demaille <a...@lrde.epita.fr> wrote:
>
> A problem was found in Bison 3.1.90: in modern C++ the parser stack
> failed to grow properly.
>
> So we are very happy to announce Bison 3.1.91, a beta of the forthcoming
> Bison 3.2. Massive improvements were brought to the deterministic C++
> skeleton, lalr1.cc. When variants are enabled and the compiler supports
> C++11 or better, move-only types can now be used for semantic values. C++98
> support is not deprecated.
>
> We expect to release Bison 3.2 within a couple of weeks. If you are a user
> of Bison's lalr1.cc, and you are using modern C++ (C++11 or newer), *please*
> try this version now. We are especially interested in usability and
> performance feedback: does your grammar look nicer, does your parser run
> faster. Any suggestion will be welcomed.
>
> Many thanks to Frank Heckenbach for paving the way for this release with his
> implementation of a C++17 skeleton.
>
>
> Here are the compressed sources:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz (4.1MB)
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz (2.1MB)
>
> Here are the GPG detached signatures[*]:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz.sig
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact. First, be sure to download both the .sig file
> and the corresponding tarball. Then, run a command like this:
>
> gpg --verify bison-3.1.91.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
> Autoconf 2.69
> Automake 1.16.1
> Flex 2.6.4
> Gettext 0.19.8.1
> Gnulib v0.1-2176-ga79f2a287
>
> NEWS
>
> * Noteworthy changes in release 3.1.91 (2018-10-18) [beta]
>
> ** Bug fixes
>
> With modern C++, the parser stack failed to grow properly.
>
> * Noteworthy changes in release 3.1.90 (2018-10-17) [beta]
>
> ** Backward incompatible changes
>
> Support for DJGPP, which have been unmaintained and untested for years, is
> obsolete. Unless there is activity to revive it, it will be removed.
>
> ** New features
>
> *** C++: Support for move semantics (lalr1.cc)
>
> The lalr1.cc skeleton now fully supports C++ move semantics, while
> maintaining compatibility with C++98. You may now store move-only types
> when using Bison's variants. For instance:
>
> %code {
> #include <memory>
> #include <vector>
> }
>
> %skeleton "lalr1.cc"
> %define api.value.type variant
>
> %%
>
> %token <int> INT "int";
> %type <std::unique_ptr<int>> int;
> %type <std::vector<std::unique_ptr<int>>> list;
>
> list:
> %empty {}
> | list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
>
> int: "int" { $$ = std::make_unique<int>($1); }
>
> *** C++: Implicit move of right-hand side values (lalr1.cc)
>
> In modern C++ (C++11 and later), you should always use 'std::move' with
> the values of the right-hand side symbols ($1, $2, etc.), as they will be
> popped from the stack anyway. Using 'std::move' is mandatory for
> move-only types such as unique_ptr, and it provides a significant speedup
> for large types such as std::string, or std::vector, etc.
>
> If '%define api.value.automove' is set, every occurrence '$n' is replaced
> by 'std::move ($n)'. The second rule in the previous grammar can be
> simplified to:
>
> list: list int { $$ = $1; $$.emplace_back($2); }
>
> With automove enabled, the semantic values are no longer lvalues, so do
> not use the swap idiom:
>
> list: list int { std::swap($$, $1); $$.emplace_back($2); }
>
> This idiom is anyway obsolete: it is preferable to move than to swap.
>
> A warning is issued when automove is enabled, and a value is used several
> times.
>
> input.yy:16.31-32: warning: multiple occurrences of $2 with
> api.value.automove enabled [-Wother]
> exp: "twice" exp { $$ = $2 + $2; }
> ^^
>
> Enabling api.value.automove does not require support for modern C++. The
> generated code is valid C++98/03, but will use copies instead of moves.
>
> The new examples/variant-11.yy shows these features in action.
>
> *** C++: The implicit default semantic action is always run
>
> When variants are enabled, the default action was not run, so
>
> exp: "number"
>
> was equivalent to
>
> exp: "number" {}
>
> It now behaves like in all the other cases, as
>
> exp: "number" { $$ = $1; }
>
> possibly using std::move if automove is enabled.
>
> We do not expect backward compatibility issues. However, beware of
> forward compatibility issues: if you rely on default actions with
> variants, be sure to '%require "3.2"' to avoid older versions of Bison to
> generate incorrect parsers.
>
> *** C++: Renaming location.hh
>
> When both %defines and %locations are enabled, Bison generates a
> location.hh file. If you don't use locations outside of the parser, you
> may avoid its creation with:
>
> %define api.location.file none
>
> However this file is useful if, for instance, your parser builds an AST
> decorated with locations: you may use Bison's location independently of
> Bison's parser. You can now give it another name, for instance:
>
> %define api.location.file "my-location.hh"
>
> This name can have directory components, and even be absolute. The name
> under which the location file is included is controlled by
> api.location.include.
>
> This way it is possible to have several parsers share the same location
> file.
>
> For instance, in src/foo/parser.hh, generate the include/ast/loc.hh file:
>
> %locations
> %define api.namespace {foo}
> %define api.location.file "include/ast/loc.hh"
> %define api.location.include {<ast/loc.hh>}
>
> and use it in src/bar/parser.hh:
>
> %locations
> %define api.namespace {bar}
> %code requires {#include <ast/loc.hh>}
> %define api.location.type {bar::location}
>
> Absolute file names are supported, so in your Makefile, passing the flag
> -Dapi.location.file='"$(top_srcdir)/include/ast/location.hh"' to bison is
> safe.
>
> *** C++: stack.hh and position.hh are deprecated
>
> When asked to generate a header file (%defines), the lalr1.cc skeleton
> generates a stack.hh file. This file had no interest for users; it is now
> made useless: its content is included in the parser definition. It is
> still generated for backward compatibility.
>
> When in addition to %defines, location support is requested (%locations),
> the file position.hh is also generated. It is now also useless: its
> content is now included in location.hh.
>
> These files are no longer generated when your grammar file requires at
> least Bison 3.2 (%require "3.2").
>
> ** Bug fixes
>
> Portability issues on MinGW and VS2015.
>
> Portability issues in the test suite.
>
> Portability/warning issues with Flex.
>
>
> _______________________________________________
> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
