bison-3.1

[Bruce Dubbs]

New minor version.

[Bruce Dubbs]

• 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.

• Reports include the type of the symbols

The sections about terminal and nonterminal symbols of the '*.output' file now specify their declared type.

• Diagnostics about useless rules

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

• 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

• 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
• 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'.

[Bruce Dubbs]

Fixed at revision 11463.