Re: bison-3.1.91 released [beta]

[Derek Clegg]

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 <address@hidden> 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.
> 
> 
> _______________________________________________
> address@hidden https://lists.gnu.org/mailman/listinfo/help-bison