Updated: bison-2.7-1

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Sat Mar 2 20:50:00 GMT 2013

A new version of 'bison' is available for download.  This updates the
package to the latest version available from ftp.gnu.org.  Relevant
portions of the Bison NEWS file are at the end of this message.

If you have questions or comments, please send them to the Cygwin
mailing list.  I would appreciate it if you would use the mailing list
rather than emailing me directly.



* Noteworthy changes in release 2.7 (2012-12-12) [stable]

** Bug fixes

  Warnings about uninitialized yylloc in yyparse have been fixed.

  Restored C90 compliance (yet no report was ever made).

** Diagnostics are improved

*** Changes in the format of error messages

  This used to be the format of many error reports:

    input.y:2.7-12: %type redeclaration for exp
    input.y:1.7-12: previous declaration

  It is now:

    input.y:2.7-12: error: %type redeclaration for exp
    input.y:1.7-12:     previous declaration

*** New format for error reports: carets

  Caret errors have been added to Bison:

    input.y:2.7-12: error: %type redeclaration for exp
     %type <sval> exp
    input.y:1.7-12:     previous declaration
     %type <ival> exp


    input.y:3.20-23: error: ambiguous reference: '$exp'
     exp: exp '+' exp { $exp = $1 + $3; };
    input.y:3.1-3:       refers to: $exp at $$
     exp: exp '+' exp { $exp = $1 + $3; };
    input.y:3.6-8:       refers to: $exp at $1
     exp: exp '+' exp { $exp = $1 + $3; };
    input.y:3.14-16:     refers to: $exp at $3
     exp: exp '+' exp { $exp = $1 + $3; };

  The default behaviour for now is still not to display these unless
  explictly asked with -fcaret (or -fall). However, in a later release, it
  will be made the default behavior (but may still be deactivated with

** New value for %define variable: api.pure full

  The %define variable api.pure requests a pure (reentrant) parser. However,
  for historical reasons, using it in a location-tracking Yacc parser
  resulted in a yyerror function that did not take a location as a
  parameter. With this new value, the user may request a better pure parser,
  where yyerror does take a location as a parameter (in location-tracking

  The use of "%define api.pure true" is deprecated in favor of this new
  "%define api.pure full".

** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)

  The %define variable api.location.type defines the name of the type to use
  for locations.  When defined, Bison no longer generates the position.hh
  and location.hh files, nor does the parser will include them: the user is
  then responsible to define her type.

  This can be used in programs with several parsers to factor their location
  and position files: let one of them generate them, and the others just use

  This feature was actually introduced, but not documented, in Bison 2.5,
  under the name "location_type" (which is maintained for backward

  For consistency, lalr1.java's %define variables location_type and
  position_type are deprecated in favor of api.location.type and

** Exception safety (lalr1.cc)

  The parse function now catches exceptions, uses the %destructors to
  release memory (the lookahead symbol and the symbols pushed on the stack)
  before re-throwing the exception.

  This feature is somewhat experimental.  User feedback would be

** Graph improvements in DOT and XSLT

  The graphical presentation of the states is more readable: their shape is
  now rectangular, the state number is clearly displayed, and the items are
  numbered and left-justified.

  The reductions are now explicitly represented as transitions to other
  diamond shaped nodes.

  These changes are present in both --graph output and xml2dot.xsl XSLT
  processing, with minor (documented) differences.

** %language is no longer an experimental feature.

  The introduction of this feature, in 2.4, was four years ago. The
  --language option and the %language directive are no longer experimental.

** Documentation

  The sections about shift/reduce and reduce/reduce conflicts resolution
  have been fixed and extended.

  Although introduced more than four years ago, XML and Graphviz reports
  were not properly documented.

  The translation of mid-rule actions is now described.

* Noteworthy changes in release 2.6.5 (2012-11-07) [stable]

  We consider compiler warnings about Bison generated parsers to be bugs.
  Rather than working around them in your own project, please consider
  reporting them to us.

** Bug fixes

  Warnings about uninitialized yylval and/or yylloc for push parsers with a
  pure interface have been fixed for GCC 4.0 up to 4.8, and Clang 2.9 to

  Other issues in the test suite have been addressed.

  Nul characters are correctly displayed in error messages.

  When possible, yylloc is correctly initialized before calling yylex.  It
  is no longer necessary to initialize it in the %initial-action.

* Noteworthy changes in release 2.6.4 (2012-10-23) [stable]

  Bison 2.6.3's --version was incorrect.  This release fixes this issue.

* Noteworthy changes in release 2.6.3 (2012-10-22) [stable]

** Bug fixes

  Bugs and portability issues in the test suite have been fixed.

  Some errors in translations have been addressed, and --help now directs
  users to the appropriate place to report them.

  Stray Info files shipped by accident are removed.

  Incorrect definitions of YY_, issued by yacc.c when no parser header is
  generated, are removed.

  All the generated headers are self-contained.

** Header guards (yacc.c, glr.c, glr.cc)

  In order to avoid collisions, the header guards are now
  YY_<PREFIX>_<FILE>_INCLUDED, instead of merely <PREFIX>_<FILE>.
  For instance the header generated from

    %define api.prefix "calc"
    %defines "lib/parse.h"

  will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.

** Fix compiler warnings in the generated parser (yacc.c, glr.c)

  The compilation of pure parsers (%define api.pure) can trigger GCC
  warnings such as:

    input.c: In function 'yyparse':
    input.c:1503:12: warning: 'yylval' may be used uninitialized in this
                              function [-Wmaybe-uninitialized]
       *++yyvsp = yylval;

  This is now fixed; pragmas to avoid these warnings are no longer needed.

  Warnings from clang ("equality comparison with extraneous parentheses" and
  "function declared 'noreturn' should not return") have also been

* Noteworthy changes in release 2.6.2 (2012-08-03) [stable]

** Bug fixes

  Buffer overruns, complaints from Flex, and portability issues in the test
  suite have been fixed.

** Spaces in %lex- and %parse-param (lalr1.cc, glr.cc)

  Trailing end-of-lines in %parse-param or %lex-param would result in
  invalid C++.  This is fixed.

** Spurious spaces and end-of-lines

  The generated files no longer end (nor start) with empty lines.

* Noteworthy changes in release 2.6.1 (2012-07-30) [stable]

  Bison no longer executes user-specified M4 code when processing a grammar.

** Future Changes

  In addition to the removal of the features announced in Bison 2.6, the
  next major release will remove the "Temporary hack for adding a semicolon
  to the user action", as announced in the release 2.5.  Instead of:

    exp: exp "+" exp { $$ = $1 + $3 };


    exp: exp "+" exp { $$ = $1 + $3; };

** Bug fixes

*** Type names are now properly escaped.

*** glr.cc: set_debug_level and debug_level work as expected.

*** Stray @ or $ in actions

  While Bison used to warn about stray $ or @ in action rules, it did not
  for other actions such as printers, destructors, or initial actions.  It
  now does.

** Type names in actions

  For consistency with rule actions, it is now possible to qualify $$ by a
  type-name in destructors, printers, and initial actions.  For instance:

    %printer { fprintf (yyo, "(%d, %f)", $<ival>$, $<fval>$); } <*> <>;

  will display two values for each typed and untyped symbol (provided
  that YYSTYPE has both "ival" and "fval" fields).

* Noteworthy changes in release 2.6 (2012-07-19) [stable]

** Future Changes

  The next major release of Bison will drop support for the following
  deprecated features.  Please report disagreements to bug-bison@gnu.org.

*** K&R C parsers

  Support for generating parsers in K&R C will be removed.  Parsers
  generated for C support ISO C90, and are tested with ISO C99 and ISO C11

*** Features deprecated since Bison 1.875

  The definitions of yystype and yyltype will be removed; use YYSTYPE and

  YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
  %lex-param, will no longer be supported.

  Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use

*** The generated header will be included (yacc.c)

  Instead of duplicating the content of the generated header (definition of
  YYSTYPE, yyparse declaration etc.), the generated parser will include it,
  as is already the case for GLR or C++ parsers.  This change is deferred
  because existing versions of ylwrap (e.g., Automake 1.12.1) do not support

** Generated Parser Headers

*** Guards (yacc.c, glr.c, glr.cc)

  The generated headers are now guarded, as is already the case for C++
  parsers (lalr1.cc).  For instance, with --defines=foo.h:

    #ifndef YY_FOO_H
    # define YY_FOO_H
    #endif /* !YY_FOO_H  */

*** New declarations (yacc.c, glr.c)

  The generated header now declares yydebug and yyparse.  Both honor
  --name-prefix=bar_, and yield

    int bar_parse (void);

  rather than

    #define yyparse bar_parse
    int yyparse (void);

  in order to facilitate the inclusion of several parser headers inside a
  single compilation unit.

*** Exported symbols in C++

  The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
  header, are removed, as they prevent the possibility of including several
  generated headers from a single compilation unit.


  For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
  longer defined.

** New %define variable: api.prefix

  Now that the generated headers are more complete and properly protected
  against multiple inclusions, constant names, such as YYSTYPE are a
  problem.  While yyparse and others are properly renamed by %name-prefix,
  YYSTYPE, YYDEBUG and others have never been affected by it.  Because it
  would introduce backward compatibility issues in projects not expecting
  YYSTYPE to be renamed, instead of changing the behavior of %name-prefix,
  it is deprecated in favor of a new %define variable: api.prefix.

  The following examples compares both:

    %name-prefix "bar_"               | %define api.prefix "bar_"
    %token <ival> FOO                   %token <ival> FOO
    %union { int ival; }                %union { int ival; }
    %%                                  %%
    exp: 'a';                           exp: 'a';

  bison generates:

    #ifndef BAR_FOO_H                   #ifndef BAR_FOO_H
    # define BAR_FOO_H                  # define BAR_FOO_H

    /* Enabling traces.  */             /* Enabling traces.  */
    # ifndef YYDEBUG                  | # ifndef BAR_DEBUG
                                      > #  if defined YYDEBUG
                                      > #   if YYDEBUG
                                      > #    define BAR_DEBUG 1
                                      > #   else
                                      > #    define BAR_DEBUG 0
                                      > #   endif
                                      > #  else
    #  define YYDEBUG 0               | #   define BAR_DEBUG 0
                                      > #  endif
    # endif                           | # endif

    # if YYDEBUG                      | # if BAR_DEBUG
    extern int bar_debug;               extern int bar_debug;
    # endif                             # endif

    /* Tokens.  */                      /* Tokens.  */
    # ifndef YYTOKENTYPE              | # ifndef BAR_TOKENTYPE
    #  define YYTOKENTYPE             | #  define BAR_TOKENTYPE
       enum yytokentype {             |    enum bar_tokentype {
         FOO = 258                           FOO = 258
       };                                  };
    # endif                             # endif

    #if ! defined YYSTYPE \           | #if ! defined BAR_STYPE \
     && ! defined YYSTYPE_IS_DECLARED |  && ! defined BAR_STYPE_IS_DECLARED
    typedef union YYSTYPE             | typedef union BAR_STYPE
    {                                   {
     int ival;                           int ival;
    } YYSTYPE;                        | } BAR_STYPE;
    # define YYSTYPE_IS_DECLARED 1    | # define BAR_STYPE_IS_DECLARED 1
    #endif                              #endif

    extern YYSTYPE bar_lval;          | extern BAR_STYPE bar_lval;

    int bar_parse (void);               int bar_parse (void);

    #endif /* !BAR_FOO_H  */            #endif /* !BAR_FOO_H  */

* Noteworthy changes in release 2.5.1 (2012-06-05) [stable]

** Future changes:

  The next major release will drop support for generating parsers in K&R C.

** yacc.c: YYBACKUP works as expected.

** glr.c improvements:

*** Location support is eliminated when not requested:

  GLR parsers used to include location-related code even when locations were
  not requested, and therefore not even usable.

*** __attribute__ is preserved:

  __attribute__ is no longer disabled when __STRICT_ANSI__ is defined (i.e.,
  when -std is passed to GCC).

** lalr1.java: several fixes:

  The Java parser no longer throws ArrayIndexOutOfBoundsException if the
  first token leads to a syntax error.  Some minor clean ups.

** Changes for C++:

*** C++11 compatibility:

  C and C++ parsers use "nullptr" instead of "0" when __cplusplus is 201103L
  or higher.

*** Header guards

  The header files such as "parser.hh", "location.hh", etc. used a constant
  name for preprocessor guards, for instance:

    # define BISON_LOCATION_HH
    #endif // !BISON_LOCATION_HH

  The inclusion guard is now computed from "PREFIX/FILE-NAME", where lower
  case characters are converted to upper case, and series of
  non-alphanumerical characters are converted to an underscore.

  With "bison -o lang++/parser.cc", "location.hh" would now include:

    # define YY_LANG_LOCATION_HH
    #endif // !YY_LANG_LOCATION_HH

*** C++ locations:

  The position and location constructors (and their initialize methods)
  accept new arguments for line and column.  Several issues in the
  documentation were fixed.

** liby is no longer asking for "rpl_fprintf" on some platforms.

** Changes in the manual:

*** %printer is documented

  The "%printer" directive, supported since at least Bison 1.50, is finally
  documented.  The "mfcalc" example is extended to demonstrate it.

  For consistency with the C skeletons, the C++ parsers now also support
  "yyoutput" (as an alias to "debug_stream ()").

*** Several improvements have been made:

  The layout for grammar excerpts was changed to a more compact scheme.
  Named references are motivated.  The description of the automaton
  description file (*.output) is updated to the current format.  Incorrect
  index entries were fixed.  Some other errors were fixed.

** Building bison:

*** Conflicting prototypes with recent/modified Flex.

  Fixed build problems with the current, unreleased, version of Flex, and
  some modified versions of 2.5.35, which have modified function prototypes.

*** Warnings during the build procedure have been eliminated.

*** Several portability problems in the test suite have been fixed:

  This includes warnings with some compilers, unexpected behavior of tools
  such as diff, warning messages from the test suite itself, etc.

*** The install-pdf target works properly:

  Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
  halts in the middle of its course.

* Changes in version 2.5 (2011-05-14):

** Grammar symbol names can now contain non-initial dashes:

  Consistently with directives (such as %error-verbose) and with
  %define variables (e.g. push-pull), grammar symbol names may contain
  dashes in any position except the beginning.  This is a GNU
  extension over POSIX Yacc.  Thus, use of this extension is reported
  by -Wyacc and rejected in Yacc mode (--yacc).

** Named references:

  Historically, Yacc and Bison have supported positional references
  ($n, $$) to allow access to symbol values from inside of semantic
  actions code.

  Starting from this version, Bison can also accept named references.
  When no ambiguity is possible, original symbol names may be used
  as named references:

    if_stmt : "if" cond_expr "then" then_stmt ';'
    { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }

  In the more common case, explicit names may be declared:

    stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
    { $res = mk_if_stmt($cond, $then, $else); }

  Location information is also accessible using @name syntax.  When
  accessing symbol names containing dots or dashes, explicit bracketing
  ($[sym.1]) must be used.

  These features are experimental in this version.  More user feedback
  will help to stabilize them.

** IELR(1) and canonical LR(1):

  IELR(1) is a minimal LR(1) parser table generation algorithm.  That
  is, given any context-free grammar, IELR(1) generates parser tables
  with the full language-recognition power of canonical LR(1) but with
  nearly the same number of parser states as LALR(1).  This reduction
  in parser states is often an order of magnitude.  More importantly,
  because canonical LR(1)'s extra parser states may contain duplicate
  conflicts in the case of non-LR(1) grammars, the number of conflicts
  for IELR(1) is often an order of magnitude less as well.  This can
  significantly reduce the complexity of developing of a grammar.

  Bison can now generate IELR(1) and canonical LR(1) parser tables in
  place of its traditional LALR(1) parser tables, which remain the
  default.  You can specify the type of parser tables in the grammar
  file with these directives:

    %define lr.type lalr
    %define lr.type ielr
    %define lr.type canonical-lr

  The default-reduction optimization in the parser tables can also be
  adjusted using "%define lr.default-reductions".  For details on both
  of these features, see the new section "Tuning LR" in the Bison

  These features are experimental.  More user feedback will help to
  stabilize them.

** LAC (Lookahead Correction) for syntax error handling:

  Canonical LR, IELR, and LALR can suffer from a couple of problems
  upon encountering a syntax error.  First, the parser might perform
  additional parser stack reductions before discovering the syntax
  error.  Such reductions can perform user semantic actions that are
  unexpected because they are based on an invalid token, and they
  cause error recovery to begin in a different syntactic context than
  the one in which the invalid token was encountered.  Second, when
  verbose error messages are enabled (with %error-verbose or the
  obsolete "#define YYERROR_VERBOSE"), the expected token list in the
  syntax error message can both contain invalid tokens and omit valid

  The culprits for the above problems are %nonassoc, default
  reductions in inconsistent states, and parser state merging.  Thus,
  IELR and LALR suffer the most.  Canonical LR can suffer only if
  %nonassoc is used or if default reductions are enabled for
  inconsistent states.

  LAC is a new mechanism within the parsing algorithm that solves
  these problems for canonical LR, IELR, and LALR without sacrificing
  %nonassoc, default reductions, or state merging.  When LAC is in
  use, canonical LR and IELR behave almost exactly the same for both
  syntactically acceptable and syntactically unacceptable input.
  While LALR still does not support the full language-recognition
  power of canonical LR and IELR, LAC at least enables LALR's syntax
  error handling to correctly reflect LALR's language-recognition

  Currently, LAC is only supported for deterministic parsers in C.
  You can enable LAC with the following directive:

    %define parse.lac full

  See the new section "LAC" in the Bison manual for additional
  details including a few caveats.

  LAC is an experimental feature.  More user feedback will help to
  stabilize it.

** %define improvements:

*** Can now be invoked via the command line:

  Each of these command-line options



  is equivalent to this grammar file declaration

    %define NAME ["VALUE"]

  except that the manner in which Bison processes multiple definitions
  for the same NAME differs.  Most importantly, -F and --force-define
  quietly override %define, but -D and --define do not.  For further
  details, see the section "Bison Options" in the Bison manual.

*** Variables renamed:

  The following %define variables


  have been renamed to


  The old names are now deprecated but will be maintained indefinitely
  for backward compatibility.

*** Values no longer need to be quoted in the grammar file:

  If a %define value is an identifier, it no longer needs to be placed
  within quotations marks.  For example,

    %define api.push-pull "push"

  can be rewritten as

    %define api.push-pull push

*** Unrecognized variables are now errors not warnings.

*** Multiple invocations for any variable is now an error not a warning.

** Unrecognized %code qualifiers are now errors not warnings.

** Character literals not of length one:

  Previously, Bison quietly converted all character literals to length
  one.  For example, without warning, Bison interpreted the operators in
  the following grammar to be the same token:

    exp: exp '++'
       | exp '+' exp

  Bison now warns when a character literal is not of length one.  In
  some future release, Bison will start reporting an error instead.

** Destructor calls fixed for lookaheads altered in semantic actions:

  Previously for deterministic parsers in C, if a user semantic action
  altered yychar, the parser in some cases used the old yychar value to
  determine which destructor to call for the lookahead upon a syntax
  error or upon parser return.  This bug has been fixed.

** C++ parsers use YYRHSLOC:

  Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
  macro and use it in the default YYLLOC_DEFAULT.  You are encouraged
  to use it.  If, for instance, your location structure has "first"
  and "last" members, instead of

    # define YYLLOC_DEFAULT(Current, Rhs, N)                             \
      do                                                                 \
        if (N)                                                           \
          {                                                              \
            (Current).first = (Rhs)[1].location.first;                   \
            (Current).last  = (Rhs)[N].location.last;                    \
          }                                                              \
        else                                                             \
          {                                                              \
            (Current).first = (Current).last = (Rhs)[0].location.last;   \
          }                                                              \
      while (false)


    # define YYLLOC_DEFAULT(Current, Rhs, N)                             \
      do                                                                 \
        if (N)                                                           \
          {                                                              \
            (Current).first = YYRHSLOC (Rhs, 1).first;                   \
            (Current).last  = YYRHSLOC (Rhs, N).last;                    \
          }                                                              \
        else                                                             \
          {                                                              \
            (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last;   \
          }                                                              \
      while (false)


  The default implementation of YYLLOC_DEFAULT used to be issued in
  the header file.  It is now output in the implementation file, after
  the user %code sections so that its #ifndef guard does not try to
  override the user's YYLLOC_DEFAULT if provided.

** YYFAIL now produces warnings and Java parsers no longer implement it:

  YYFAIL has existed for many years as an undocumented feature of
  deterministic parsers in C generated by Bison.  More recently, it was
  a documented feature of Bison's experimental Java parsers.  As
  promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
  semantic action now produces a deprecation warning, and Java parsers
  no longer implement YYFAIL at all.  For further details, including a
  discussion of how to suppress C preprocessor warnings about YYFAIL
  being unused, see the Bison 2.4.2 NEWS entry.

** Temporary hack for adding a semicolon to the user action:

  Previously, Bison appended a semicolon to every user action for
  reductions when the output language defaulted to C (specifically, when
  neither %yacc, %language, %skeleton, or equivalent command-line
  options were specified).  This allowed actions such as

    exp: exp "+" exp { $$ = $1 + $3 };

  instead of

    exp: exp "+" exp { $$ = $1 + $3; };

  As a first step in removing this misfeature, Bison now issues a
  warning when it appends a semicolon.  Moreover, in cases where Bison
  cannot easily determine whether a semicolon is needed (for example, an
  action ending with a cpp directive or a braced compound initializer),
  it no longer appends one.  Thus, the C compiler might now complain
  about a missing semicolon where it did not before.  Future releases of
  Bison will cease to append semicolons entirely.

** Verbose syntax error message fixes:

  When %error-verbose or the obsolete "#define YYERROR_VERBOSE" is
  specified, syntax error messages produced by the generated parser
  include the unexpected token as well as a list of expected tokens.
  The effect of %nonassoc on these verbose messages has been corrected
  in two ways, but a more complete fix requires LAC, described above:

*** When %nonassoc is used, there can exist parser states that accept no
    tokens, and so the parser does not always require a lookahead token
    in order to detect a syntax error.  Because no unexpected token or
    expected tokens can then be reported, the verbose syntax error
    message described above is suppressed, and the parser instead
    reports the simpler message, "syntax error".  Previously, this
    suppression was sometimes erroneously triggered by %nonassoc when a
    lookahead was actually required.  Now verbose messages are
    suppressed only when all previous lookaheads have already been
    shifted or discarded.

*** Previously, the list of expected tokens erroneously included tokens
    that would actually induce a syntax error because conflicts for them
    were resolved with %nonassoc in the current parser state.  Such
    tokens are now properly omitted from the list.

*** Expected token lists are still often wrong due to state merging
    (from LALR or IELR) and default reductions, which can both add
    invalid tokens and subtract valid tokens.  Canonical LR almost
    completely fixes this problem by eliminating state merging and
    default reductions.  However, there is one minor problem left even
    when using canonical LR and even after the fixes above.  That is,
    if the resolution of a conflict with %nonassoc appears in a later
    parser state than the one at which some syntax error is
    discovered, the conflicted token is still erroneously included in
    the expected token list.  Bison's new LAC implementation,
    described above, eliminates this problem and the need for
    canonical LR.  However, LAC is still experimental and is disabled
    by default.

** Java skeleton fixes:

*** A location handling bug has been fixed.

*** The top element of each of the value stack and location stack is now
    cleared when popped so that it can be garbage collected.

*** Parser traces now print the top element of the stack.

** -W/--warnings fixes:

*** Bison now properly recognizes the "no-" versions of categories:

  For example, given the following command line, Bison now enables all
  warnings except warnings for incompatibilities with POSIX Yacc:

    bison -Wall,no-yacc gram.y

*** Bison now treats S/R and R/R conflicts like other warnings:

  Previously, conflict reports were independent of Bison's normal
  warning system.  Now, Bison recognizes the warning categories
  "conflicts-sr" and "conflicts-rr".  This change has important
  consequences for the -W and --warnings command-line options.  For

    bison -Wno-conflicts-sr gram.y  # S/R conflicts not reported
    bison -Wno-conflicts-rr gram.y  # R/R conflicts not reported
    bison -Wnone            gram.y  # no conflicts are reported
    bison -Werror           gram.y  # any conflict is an error

  However, as before, if the %expect or %expect-rr directive is
  specified, an unexpected number of conflicts is an error, and an
  expected number of conflicts is not reported, so -W and --warning
  then have no effect on the conflict report.

*** The "none" category no longer disables a preceding "error":

  For example, for the following command line, Bison now reports
  errors instead of warnings for incompatibilities with POSIX Yacc:

    bison -Werror,none,yacc gram.y

*** The "none" category now disables all Bison warnings:

  Previously, the "none" category disabled only Bison warnings for
  which there existed a specific -W/--warning category.  However,
  given the following command line, Bison is now guaranteed to
  suppress all warnings:

    bison -Wnone gram.y

** Precedence directives can now assign token number 0:

  Since Bison 2.3b, which restored the ability of precedence
  directives to assign token numbers, doing so for token number 0 has
  produced an assertion failure.  For example:

    %left END 0

  This bug has been fixed.

* Changes in version 2.4.3 (2010-08-05):

** Bison now obeys -Werror and --warnings=error for warnings about
   grammar rules that are useless in the parser due to conflicts.

** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
   been fixed.

** Failures in the test suite for GCC 4.5 have been fixed.

** Failures in the test suite for some versions of Sun Studio C++ have
   been fixed.

** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
   warnings about undefined %prec identifiers will not be converted to
   errors in Bison 2.5.  They will remain warnings, which should be
   sufficient for POSIX while avoiding backward compatibility issues.

** Minor documentation fixes.

More information about the Cygwin-announce mailing list