GNU Bison 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 have 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.

* Noteworthy changes in release 3.1 (2018-08-27) [stable]

** Backward incompatible changes

  Compiling Bison now requires a C99 compiler---as announced during the
  release of Bison 3.0, five years ago.  Generated parsers do not require a
  C99 compiler.

  Support for DJGPP, which have been unmaintained and untested for years, is
  obsolete. Unless there is activity to revive it, the next release of Bison
  will have it removed.

** New features

*** Typed midrule actions

  Because their type is unknown to Bison, the values of midrule actions are
  not treated like the others: they don't have %printer and %destructor
  support.  It also prevents C++ (Bison) variants to handle them properly.

  Typed midrule actions address these issues.  Instead of:

    exp: { $<ival>$ = 1; } { $<ival>$ = 2; }   { $$ = $<ival>1 + $<ival>2; }

  write:

    exp: <ival>{ $$ = 1; } <ival>{ $$ = 2; }   { $$ = $1 + $2; }

*** Reports include the type of the symbols

  The sections about terminal and nonterminal symbols of the '*.output' file
  now specify their declared type.  For instance, for:

    %token <ival> NUM

  the report now shows '<ival>':

    Terminals, with rules where they appear

    NUM <ival> (258) 5

*** Diagnostics about useless rules

  In the following grammar, the 'exp' nonterminal is trivially useless.  So,
  of course, its rules are useless too.

    %%
    input: '0' | exp
    exp: exp '+' exp | exp '-' exp | '(' exp ')'

  Previously all the useless rules were reported, including those whose
  left-hand side is the 'exp' nonterminal:

    warning: 1 nonterminal useless in grammar [-Wother]
    warning: 4 rules useless in grammar [-Wother]
    2.14-16: warning: nonterminal useless in grammar: exp [-Wother]
     input: '0' | exp
                  ^^^
    2.14-16: warning: rule useless in grammar [-Wother]
     input: '0' | exp
                  ^^^
    3.6-16: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
          ^^^^^^^^^^^
    3.20-30: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
                        ^^^^^^^^^^^
    3.34-44: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
                                      ^^^^^^^^^^^

  Now, rules whose left-hand side symbol is useless are no longer reported
  as useless.  The locations of the errors have also been adjusted to point
  to the first use of the nonterminal as a left-hand side of a rule:

    warning: 1 nonterminal useless in grammar [-Wother]
    warning: 4 rules useless in grammar [-Wother]
    3.1-3: warning: nonterminal useless in grammar: exp [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
     ^^^
    2.14-16: warning: rule useless in grammar [-Wother]
     input: '0' | exp
                  ^^^

*** C++: Generated parsers can be compiled with -fno-exceptions (lalr1.cc)

  When compiled with exceptions disabled, the generated parsers no longer
  uses try/catch clauses.

  Currently only GCC and Clang are supported.

** Documentation

*** A demonstration of variants

  A new example was added (installed in .../share/doc/bison/examples),
  'variant.yy', which shows how to use (Bison) variants in C++.

  The other examples were made nicer to read.

*** Some features are no longer 'experimental'

  The following features, mature enough, are no longer flagged as
  experimental in the documentation: push parsers, default %printer and
  %destructor (typed: <*> and untyped: <>), %define api.value.type union and
  variant, Java parsers, XML output, LR family (lr, ielr, lalr), and
  semantic predicates (%?).

** Bug fixes

*** GLR: Predicates support broken by #line directives

  Predicates (%?) in GLR such as

    widget:
      %? {new_syntax} 'w' id new_args
    | %?{!new_syntax} 'w' id old_args

  were issued with #lines in the middle of C code.

*** Printer and destructor with broken #line directives

  The #line directives were not properly escaped when emitting the code for
  %printer/%destructor, which resulted in compiler errors if there are
  backslashes or double-quotes in the grammar file name.

*** Portability on ICC

  The Intel compiler claims compatibility with GCC, yet rejects its _Pragma.
  Generated parsers now work around this.

*** Various

  There were several small fixes in the test suite and in the build system,
  many warnings in bison and in the generated parsers were eliminated.  The
  documentation also received its share of minor improvements.

  Useless code was removed from C++ parsers, and some of the generated
  constructors are more 'natural'.

* Noteworthy changes in release 3.0.5 (2018-05-27) [stable]

** Bug fixes

*** C++: Fix support of 'syntax_error'

  One incorrect 'inline' resulted in linking errors about the constructor of
  the syntax_error exception.

*** C++: Fix warnings

  GCC 7.3 (with -O1 or -O2 but not -O0 or -O3) issued null-dereference
  warnings about yyformat being possibly null.  It also warned about the
  deprecated implicit definition of copy constructors when there's a
  user-defined (copy) assignment operator.

*** Location of errors

  In C++ parsers, out-of-bounds errors can happen when a rule with an empty
  ride-hand side raises a syntax error.  The behavior of the default parser
  (yacc.c) in such a condition was undefined.

  Now all the parsers match the behavior of glr.c: @$ is used as the
  location of the error.  This handles gracefully rules with and without
  rhs.

*** Portability fixes in the test suite

  On some platforms, some Java and/or C++ tests were failing.

* Noteworthy changes in release 3.0.4 (2015-01-23) [stable]

** Bug fixes

*** C++ with Variants (lalr1.cc)

  Fix a compiler warning when no %destructor use $$.

*** Test suites

  Several portability issues in tests were fixed.

* Noteworthy changes in release 3.0.3 (2015-01-15) [stable]

** Bug fixes

*** C++ with Variants (lalr1.cc)

  Problems with %destructor and '%define parse.assert' have been fixed.

*** Named %union support (yacc.c, glr.c)

  Bison 3.0 introduced a regression on named %union such as

    %union foo { int ival; };

  The possibility to use a name was introduced "for Yacc compatibility".
  It is however not required by POSIX Yacc, and its usefulness is not clear.

*** %define api.value.type union with %defines (yacc.c, glr.c)

  The C parsers were broken when %defines was used together with "%define
  api.value.type union".

*** Redeclarations are reported in proper order

  On

    %token FOO "foo"
    %printer {} "foo"
    %printer {} FOO

  bison used to report:

    /tmp/foo.yy:2.10-11: error: %printer redeclaration for FOO
     %printer {} "foo"
              ^^
    /tmp/foo.yy:3.10-11:     previous declaration
     %printer {} FOO
              ^^

  Now, the "previous" declaration is always the first one.


** Documentation

  Bison now installs various files in its docdir (which defaults to
  '/usr/local/share/doc/bison'), including the three fully blown examples
  extracted from the documentation:

   - rpcalc
     Reverse Polish Calculator, a simple introductory example.
   - mfcalc
     Multi-function Calc, a calculator with memory and functions and located
     error messages.
   - calc++
     a calculator in C++ using variant support and token constructors.

* Noteworthy changes in release 3.0.2 (2013-12-05) [stable]

** Bug fixes

*** Generated source files when errors are reported

  When warnings are issued and -Werror is set, bison would still generate
  the source files (*.c, *.h...).  As a consequence, some runs of "make"
  could fail the first time, but not the second (as the files were generated
  anyway).

  This is fixed: bison no longer generates this source files, but, of
  course, still produces the various reports (*.output, *.xml, etc.).

*** %empty is used in reports

  Empty right-hand sides are denoted by '%empty' in all the reports (text,
  dot, XML and formats derived from it).

*** YYERROR and variants

  When C++ variant support is enabled, an error triggered via YYERROR, but
  not caught via error recovery, resulted in a double deletion.

* Noteworthy changes in release 3.0.1 (2013-11-12) [stable]

** Bug fixes

*** Errors in caret diagnostics

  On some platforms, some errors could result in endless diagnostics.

*** Fixes of the -Werror option

  Options such as "-Werror -Wno-error=foo" were still turning "foo"
  diagnostics into errors instead of warnings.  This is fixed.

  Actually, for consistency with GCC, "-Wno-error=foo -Werror" now also
  leaves "foo" diagnostics as warnings.  Similarly, with "-Werror=foo
  -Wno-error", "foo" diagnostics are now errors.

*** GLR Predicates

  As demonstrated in the documentation, one can now leave spaces between
  "%?" and its "{".

*** Installation

  The yacc.1 man page is no longer installed if --disable-yacc was
  specified.

*** Fixes in the test suite

  Bugs and portability issues.

* Noteworthy changes in release 3.0 (2013-07-25) [stable]

** WARNING: Future backward-incompatibilities!

  Like other GNU packages, Bison will start using some of the C99 features
  for its own code, especially the definition of variables after statements.
  The generated C parsers still aim at C90.

** Backward incompatible changes

*** Obsolete features

  Support for YYFAIL is removed (deprecated in Bison 2.4.2): use YYERROR.

  Support for yystype and yyltype is removed (deprecated in Bison 1.875):
  use YYSTYPE and YYLTYPE.

  Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
  1.875): use %lex-param, %parse-param, or %param.

  Missing semicolons at the end of actions are no longer added (as announced
  in the release 2.5).

*** Use of YACC='bison -y'

  TL;DR: With Autoconf <= 2.69, pass -Wno-yacc to (AM_)YFLAGS if you use
  Bison extensions.

  Traditional Yacc generates 'y.tab.c' whatever the name of the input file.
  Therefore Makefiles written for Yacc expect 'y.tab.c' (and possibly
  'y.tab.h' and 'y.outout') to be generated from 'foo.y'.

  To this end, for ages, AC_PROG_YACC, Autoconf's macro to look for an
  implementation of Yacc, was using Bison as 'bison -y'.  While it does
  ensure compatible output file names, it also enables warnings for
  incompatibilities with POSIX Yacc.  In other words, 'bison -y' triggers
  warnings for Bison extensions.

  Autoconf 2.70+ fixes this incompatibility by using YACC='bison -o y.tab.c'
  (which also generates 'y.tab.h' and 'y.output' when needed).
  Alternatively, disable Yacc warnings by passing '-Wno-yacc' to your Yacc
  flags (YFLAGS, or AM_YFLAGS with Automake).

** Bug fixes

*** The epilogue is no longer affected by internal #defines (glr.c)

  The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
  generated code.  These weren't properly undefined before the inclusion of
  the user epilogue, so functions such as the following were butchered by the
  preprocessor expansion:

    int yylex (YYSTYPE *yylval);

  This is fixed: yylval, yynerrs, yychar, and yylloc are now valid
  identifiers for user-provided variables.

*** stdio.h is no longer needed when locations are enabled (yacc.c)

  Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
  locations are enabled.  This is fixed.

*** Warnings about useless %pure-parser/%define api.pure are restored

** Diagnostics reported by Bison

  Most of these features were contributed by Théophile Ranquet and Victor
  Santet.

*** Carets

  Version 2.7 introduced caret errors, for a prettier output.  These are now
  activated by default.  The old format can still be used by invoking Bison
  with -fno-caret (or -fnone).

  Some error messages that reproduced excerpts of the grammar are now using
  the caret information only.  For instance on:

    %%
    exp: 'a' | 'a';

  Bison 2.7 reports:

    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
    in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]

  Now bison reports:

    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
    in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
     exp: 'a' | 'a';
                ^^^

  and "bison -fno-caret" reports:

    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
    in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]

*** Enhancements of the -Werror option

  The -Werror=CATEGORY option is now recognized, and will treat specified
  warnings as errors. The warnings need not have been explicitly activated
  using the -W option, this is similar to what GCC 4.7 does.

  For example, given the following command line, Bison will treat both
  warnings related to POSIX Yacc incompatibilities and S/R conflicts as
  errors (and only those):

    $ bison -Werror=yacc,error=conflicts-sr input.y

  If no categories are specified, -Werror will make all active warnings into
  errors. For example, the following line does the same the previous example:

    $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y

  (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)

  Note that the categories in this -Werror option may not be prefixed with
  "no-". However, -Wno-error[=CATEGORY] is valid.

  Note that -y enables -Werror=yacc. Therefore it is now possible to require
  Yacc-like behavior (e.g., always generate y.tab.c), but to report
  incompatibilities as warnings: "-y -Wno-error=yacc".

*** The display of warnings is now richer

  The option that controls a given warning is now displayed:

    foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]

  In the case of warnings treated as errors, the prefix is changed from
  "warning: " to "error: ", and the suffix is displayed, in a manner similar
  to GCC, as [-Werror=CATEGORY].

  For instance, where the previous version of Bison would report (and exit
  with failure):

    bison: warnings being treated as errors
    input.y:1.1: warning: stray ',' treated as white space

  it now reports:

    input.y:1.1: error: stray ',' treated as white space [-Werror=other]

*** Deprecated constructs

  The new 'deprecated' warning category flags obsolete constructs whose
  support will be discontinued.  It is enabled by default.  These warnings
  used to be reported as 'other' warnings.

*** Useless semantic types

  Bison now warns about useless (uninhabited) semantic types.  Since
  semantic types are not declared to Bison (they are defined in the opaque
  %union structure), it is %printer/%destructor directives about useless
  types that trigger the warning:

    %token <type1> term
    %type  <type2> nterm
    %printer    {} <type1> <type3>
    %destructor {} <type2> <type4>
    %%
    nterm: term { $$ = $1; };

    3.28-34: warning: type <type3> is used, but is not associated to any symbol
    4.28-34: warning: type <type4> is used, but is not associated to any symbol

*** Undefined but unused symbols

  Bison used to raise an error for undefined symbols that are not used in
  the grammar.  This is now only a warning.

    %printer    {} symbol1
    %destructor {} symbol2
    %type <type>   symbol3
    %%
    exp: "a";

*** Useless destructors or printers

  Bison now warns about useless destructors or printers.  In the following
  example, the printer for <type1>, and the destructor for <type2> are
  useless: all symbols of <type1> (token1) already have a printer, and all
  symbols of type <type2> (token2) already have a destructor.

    %token <type1> token1
           <type2> token2
           <type3> token3
           <type4> token4
    %printer    {} token1 <type1> <type3>
    %destructor {} token2 <type2> <type4>

*** Conflicts

  The warnings and error messages about shift/reduce and reduce/reduce
  conflicts have been normalized.  For instance on the following foo.y file:

    %glr-parser
    %%
    exp: exp '+' exp | '0' | '0';

  compare the previous version of bison:

    $ bison foo.y
    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
    $ bison -Werror foo.y
    bison: warnings being treated as errors
    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce

  with the new behavior:

    $ bison foo.y
    foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
    foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
    $ bison -Werror foo.y
    foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
    foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]

  When %expect or %expect-rr is used, such as with bar.y:

    %expect 0
    %glr-parser
    %%
    exp: exp '+' exp | '0' | '0';

  Former behavior:

    $ bison bar.y
    bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
    bar.y: expected 0 shift/reduce conflicts
    bar.y: expected 0 reduce/reduce conflicts

  New one:

    $ bison bar.y
    bar.y: error: shift/reduce conflicts: 1 found, 0 expected
    bar.y: error: reduce/reduce conflicts: 2 found, 0 expected

** Incompatibilities with POSIX Yacc

  The 'yacc' category is no longer part of '-Wall', enable it explicitly
  with '-Wyacc'.

** Additional yylex/yyparse arguments

  The new directive %param declares additional arguments to both yylex and
  yyparse.  The %lex-param, %parse-param, and %param directives support one
  or more arguments.  Instead of

    %lex-param   {arg1_type *arg1}
    %lex-param   {arg2_type *arg2}
    %parse-param {arg1_type *arg1}
    %parse-param {arg2_type *arg2}

  one may now declare

    %param {arg1_type *arg1} {arg2_type *arg2}

** Types of values for %define variables

  Bison used to make no difference between '%define foo bar' and '%define
  foo "bar"'.  The former is now called a 'keyword value', and the latter a
  'string value'.  A third kind was added: 'code values', such as '%define
  foo {bar}'.

  Keyword variables are used for fixed value sets, e.g.,

    %define lr.type lalr

  Code variables are used for value in the target language, e.g.,

    %define api.value.type {struct semantic_type}

  String variables are used remaining cases, e.g. file names.

** Variable api.token.prefix

  The variable api.token.prefix changes the way tokens are identified in
  the generated files.  This is especially useful to avoid collisions
  with identifiers in the target language.  For instance

    %token FILE for ERROR
    %define api.token.prefix {TOK_}
    %%
    start: FILE for ERROR;

  will generate the definition of the symbols TOK_FILE, TOK_for, and
  TOK_ERROR in the generated sources.  In particular, the scanner must
  use these prefixed token names, although the grammar itself still
  uses the short names (as in the sample rule given above).

** Variable api.value.type

  This new %define variable supersedes the #define macro YYSTYPE.  The use
  of YYSTYPE is discouraged.  In particular, #defining YYSTYPE *and* either
  using %union or %defining api.value.type results in undefined behavior.

  Either define api.value.type, or use "%union":

    %union
    {
      int ival;
      char *sval;
    }
    %token <ival> INT "integer"
    %token <sval> STRING "string"
    %printer { fprintf (yyo, "%d", $$); } <ival>
    %destructor { free ($$); } <sval>

    /* In yylex().  */
    yylval.ival = 42; return INT;
    yylval.sval = "42"; return STRING;

  The %define variable api.value.type supports both keyword and code values.

  The keyword value 'union' means that the user provides genuine types, not
  union member names such as "ival" and "sval" above (WARNING: will fail if
  -y/--yacc/%yacc is enabled).

    %define api.value.type union
    %token <int> INT "integer"
    %token <char *> STRING "string"
    %printer { fprintf (yyo, "%d", $$); } <int>
    %destructor { free ($$); } <char *>

    /* In yylex().  */
    yylval.INT = 42; return INT;
    yylval.STRING = "42"; return STRING;

  The keyword value variant is somewhat equivalent, but for C++ special
  provision is made to allow classes to be used (more about this below).

    %define api.value.type variant
    %token <int> INT "integer"
    %token <std::string> STRING "string"

  Code values (in braces) denote user defined types.  This is where YYSTYPE
  used to be used.

    %code requires
    {
      struct my_value
      {
        enum
        {
          is_int, is_string
        } kind;
        union
        {
          int ival;
          char *sval;
        } u;
      };
    }
    %define api.value.type {struct my_value}
    %token <u.ival> INT "integer"
    %token <u.sval> STRING "string"
    %printer { fprintf (yyo, "%d", $$); } <u.ival>
    %destructor { free ($$); } <u.sval>

    /* In yylex().  */
    yylval.u.ival = 42; return INT;
    yylval.u.sval = "42"; return STRING;

** Variable parse.error

  This variable controls the verbosity of error messages.  The use of the
  %error-verbose directive is deprecated in favor of "%define parse.error
  verbose".

** Renamed %define variables

  The following variables have been renamed for consistency.  Backward
  compatibility is ensured, but upgrading is recommended.

    lr.default-reductions      -> lr.default-reduction
    lr.keep-unreachable-states -> lr.keep-unreachable-state
    namespace                  -> api.namespace
    stype                      -> api.value.type

** Semantic predicates

  Contributed by Paul Hilfinger.

  The new, experimental, semantic-predicate feature allows actions of the
  form "%?{ BOOLEAN-EXPRESSION }", which cause syntax errors (as for
  YYERROR) if the expression evaluates to 0, and are evaluated immediately
  in GLR parsers, rather than being deferred.  The result is that they allow
  the programmer to prune possible parses based on the values of run-time
  expressions.

** The directive %expect-rr is now an error in non GLR mode

  It used to be an error only if used in non GLR mode, _and_ if there are
  reduce/reduce conflicts.

** Tokens are numbered in their order of appearance

  Contributed by Valentin Tolmer.

  With '%token A B', A had a number less than the one of B.  However,
  precedence declarations used to generate a reversed order.  This is now
  fixed, and introducing tokens with any of %token, %left, %right,
  %precedence, or %nonassoc yields the same result.

  When mixing declarations of tokens with a literal character (e.g., 'a') or
  with an identifier (e.g., B) in a precedence declaration, Bison numbered
  the literal characters first.  For example

    %right A B 'c' 'd'

  would lead to the tokens declared in this order: 'c' 'd' A B.  Again, the
  input order is now preserved.

  These changes were made so that one can remove useless precedence and
  associativity declarations (i.e., map %nonassoc, %left or %right to
  %precedence, or to %token) and get exactly the same output.

** Useless precedence and associativity

  Contributed by Valentin Tolmer.

  When developing and maintaining a grammar, useless associativity and
  precedence directives are common.  They can be a nuisance: new ambiguities
  arising are sometimes masked because their conflicts are resolved due to
  the extra precedence or associativity information.  Furthermore, it can
  hinder the comprehension of a new grammar: one will wonder about the role
  of a precedence, where in fact it is useless.  The following changes aim
  at detecting and reporting these extra directives.

*** Precedence warning category

  A new category of warning, -Wprecedence, was introduced. It flags the
  useless precedence and associativity directives.

*** Useless associativity

  Bison now warns about symbols with a declared associativity that is never
  used to resolve conflicts.  In that case, using %precedence is sufficient;
  the parsing tables will remain unchanged.  Solving these warnings may raise
  useless precedence warnings, as the symbols no longer have associativity.
  For example:

    %left '+'
    %left '*'
    %%
    exp:
      "number"
    | exp '+' "number"
    | exp '*' exp
    ;

  will produce a

    warning: useless associativity for '+', use %precedence [-Wprecedence]
     %left '+'
           ^^^

*** Useless precedence

  Bison now warns about symbols with a declared precedence and no declared
  associativity (i.e., declared with %precedence), and whose precedence is
  never used.  In that case, the symbol can be safely declared with %token
  instead, without modifying the parsing tables.  For example:

    %precedence '='
    %%
    exp: "var" '=' "number";

  will produce a

    warning: useless precedence for '=' [-Wprecedence]
     %precedence '='
                 ^^^

*** Useless precedence and associativity

  In case of both useless precedence and associativity, the issue is flagged
  as follows:

    %nonassoc '='
    %%
    exp: "var" '=' "number";

  The warning is:

    warning: useless precedence and associativity for '=' [-Wprecedence]
     %nonassoc '='
               ^^^

** Empty rules

  With help from Joel E. Denny and Gabriel Rassoul.

  Empty rules (i.e., with an empty right-hand side) can now be explicitly
  marked by the new %empty directive.  Using %empty on a non-empty rule is
  an error.  The new -Wempty-rule warning reports empty rules without
  %empty.  On the following grammar:

    %%
    s: a b c;
    a: ;
    b: %empty;
    c: 'a' %empty;

  bison reports:

    3.4-5: warning: empty rule without %empty [-Wempty-rule]
     a: {}
        ^^
    5.8-13: error: %empty on non-empty rule
     c: 'a' %empty {};
            ^^^^^^

** Java skeleton improvements

  The constants for token names were moved to the Lexer interface.  Also, it
  is possible to add code to the parser's constructors using "%code init"
  and "%define init_throws".
  Contributed by Paolo Bonzini.

  The Java skeleton now supports push parsing.
  Contributed by Dennis Heimbigner.

** C++ skeletons improvements

