Bison 3.2.2 released [stable]

[Akim Demaille]

Bison 3.2.2 is a bug fix release of Bison 3.2.

Bison 3.2 brought massive improvements 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.  Please see the NEWS below for more details.

Many thanks to Frank Heckenbach for paving the way for this release with his
implementation of a skeleton in C++17, and to Nelson H. F. Beebe for testing
exhaustively portability issues.

==================================================================

Bison is a general-purpose parser generator that converts an annotated
context-free grammar into a deterministic LR or generalized LR (GLR) parser
employing LALR(1) parser tables.  Bison can also generate IELR(1) or
canonical LR(1) parser tables. Once you are proficient with Bison, you can
use it to develop a wide range of language parsers, from those used in
simple desk calculators to complex programming languages.

Bison is upward compatible with Yacc: all properly-written Yacc grammars
ought to work with Bison with no change. Anyone familiar with Yacc should be
able to use Bison with little trouble. You need to be fluent in C or C++
programming in order to use Bison. Java is also supported.

Here is the GNU Bison home page:
   https://gnu.org/software/bison/

==================================================================

Here are the compressed sources:
  https://ftp.gnu.org/gnu/bison/bison-3.2.2.tar.gz   (4.1MB)
  https://ftp.gnu.org/gnu/bison/bison-3.2.2.tar.xz   (2.1MB)

Here are the GPG detached signatures[*]:
  https://ftp.gnu.org/gnu/bison/bison-3.2.2.tar.gz.sig
  https://ftp.gnu.org/gnu/bison/bison-3.2.2.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.2.2.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-2222-g48a6c46b0

NEWS

* Noteworthy changes in release 3.2.2 (2018-11-21) [stable]

** Bug fixes

  C++ portability issues.

* Noteworthy changes in release 3.2.1 (2018-11-09) [stable]

** Bug fixes

  Several portability issues have been fixed in the build system, in the
  test suite, and in the generated parsers in C++.

* Noteworthy changes in release 3.2 (2018-10-29) [stable]

** Backward incompatible changes

  Support for DJGPP, which has been unmaintained and untested for years, is
  obsolete.  Unless there is activity to revive it, it will be removed.

** Changes

  %printers should use yyo rather than yyoutput to denote the output stream.

  Variant-based symbols in C++ should use emplace() rather than build().

  In C++ parsers, parser::operator() is now a synonym for the parser::parse.

** Documentation

  A new section, "A Simple C++ Example", is a tutorial for parsers in C++.

  A comment in the generated code now emphasizes that users should not
  depend upon non-documented implementation details, such as macros starting
  with YY_.

** 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/c++/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.