We are very happy to announce the release of Bison 3.5, the best release
ever of Bison! Better than 3.4, although it was a big improvement over 3.3,
which was huge upgrade compared to 3.2, itself way ahead Bison 3.1. Ethic
demands that we don't mention 3.0. Rumor has it that Bison 3.5 is not as
good as 3.6 will be though...
Paul Eggert revised the use of integral types in both the generator and the
generated parsers. As a consequence small parsers have a smaller footprint,
and very large automata are now possible with the default back-end (yacc.c).
If you are interested in smaller parsers, also have a look at api.token.raw.
Adrian Vogelsgesang contributed lookahead correction for C++.
The purpose of string literals has been clarified. Indeed, they are used
for two different purposes: freeing from having to implement the keyword
matching in the scanner, and improving error messages. Most of the time
both can be achieved at the same time, but on occasions, it does not work so
well. We promote their use for error messages. We still support the former
case (at least for historical skeletons), but it is _not_ a recommended
practice. The documentation now warns against this use. A new warning,
-Wdangling-alias, should help users who want to enforce the use of aliases
only for error messages.
An experimental back-end for the D programming language was added thanks to
Oliver Mangold and H. S. Teoh. It is looking for active support from the D
community.
See below for more details about this release.
Happy parsing!
==
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
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, C++ or Java
programming in order to use Bison.
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.5.tar.gz (5.1MB)
https://ftp.gnu.org/gnu/bison/bison-3.5.tar.xz (3.1MB)
Here are the GPG detached signatures[*]:
https://ftp.gnu.org/gnu/bison/bison-3.5.tar.gz.sig
https://ftp.gnu.org/gnu/bison/bison-3.5.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.5.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-2971-gb943dd664
==
* Noteworthy changes in release 3.5 (2019-12-11) [stable]
** Backward incompatible changes
Lone carriage-return characters (aka \r or ^M) in the grammar files are no
longer treated as end-of-lines. This changes the diagnostics, and in
particular their locations.
In C++, line numbers and columns are now represented as 'int' not
'unsigned', so that integer overflow on positions is easily checkable via
'gcc -fsanitize=undefined' and the like. This affects the API for
positions. The default position and location classes now expose
'counter_type' (int), used to define line and column numbers.
** Deprecated features
The YYPRINT macro, which works only with yacc.c and only for tokens, was
obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
It is deprecated and its support will be removed eventually.
** New features
*** Lookahead correction in C++
Contributed by Adrian Vogelsgesang.
The C++ deterministic skeleton (lalr1.cc) now supports LAC, via the
%define variable parse.lac.
*** Variable api.token.raw: Optimized token numbers (all skeletons)
In the generated parsers, tokens have two numbers: the "external" token
number as returned by yylex (which starts at 257), and the "internal"
symbol number (which starts at 3). Each time yylex is called, a table
lookup maps the external token number to the internal symbol number.
When the %define variable api.token.raw is set, tokens are assigned their
internal number, which sa