[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bison 3.6.90 released [beta]
From: |
Akim Demaille |
Subject: |
Bison 3.6.90 released [beta] |
Date: |
Sat, 4 Jul 2020 14:57:49 +0200 |
Hi all,
I am super excited to announce the forthcoming release of Bison 3.7, whose
main novelty, contributed by Vincent Imbimbo, is the generation of
counterexamples for conflicts. For instance on a grammar featuring the
infamous "dangling else" problem, "bison -Wcounterexamples" now gives:
dangling.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
Shift/reduce conflict on token "else":
Example "if" exp "if" exp exp • "else" exp
First derivation exp ::=[ "if" exp exp ::=[ "if" exp exp • ] "else" exp ]
Second derivation exp ::=[ "if" exp exp ::=[ "if" exp exp • "else" exp ] ]
which proves that the grammar is ambiguous by exhibiting a test sample with
two derivations (corresponding to two parse trees).
When Bison is installed with text styling enabled, the example is actually
shown twice, with colors demonstrating the ambiguity (see
https://www.lrde.epita.fr/~akim/private/bison/dangling-else.png).
Joshua Watt contributed the option `--file-prefix-map OLD=NEW`, to make
reproducible builds.
See the NEWS below for more details.
We *need* feedback on this beta. Not just on counterexamples, there were
other changes affecting all the skeletons.
*Please* *,* *pretty* *please* *,* *test* *it* *!*
Feedback on the format of the counterexamples would also be most useful.
Cheers!
Akim
PS/ The experimental back-end for the D programming language is still
looking for active support from the D community.
==================================================================
GNU 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.
Bison and the parsers it generates are portable, they do not require any
specific compilers.
GNU Bison's home page is https://gnu.org/software/bison/.
==================================================================
Here are the compressed sources:
https://alpha.gnu.org/gnu/bison/bison-3.6.90.tar.gz (5.1MB)
https://alpha.gnu.org/gnu/bison/bison-3.6.90.tar.lz (3.1MB)
https://alpha.gnu.org/gnu/bison/bison-3.6.90.tar.xz (3.1MB)
Here are the GPG detached signatures[*]:
https://alpha.gnu.org/gnu/bison/bison-3.6.90.tar.gz.sig
https://alpha.gnu.org/gnu/bison/bison-3.6.90.tar.lz.sig
https://alpha.gnu.org/gnu/bison/bison-3.6.90.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.6.90.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.2
Flex 2.6.4
Gettext 0.19.8.1
Gnulib v0.1-3594-g845d69187
==================================================================
* Noteworthy changes in release 3.6.90 (2020-07-04) [beta]
** 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.
In conformance with the recommendations of the Graphviz team, in the next
version Bison the option `--graph` will generate a *.gv file by default,
instead of *.dot. A transition started in Bison 3.4.
** New features
*** Counterexample Generation
Contributed by Vincent Imbimbo.
When given `--report=counterexamples` or `-Wcounterexamples`, bison will
now output counterexamples for conflicts in the grammar. These are
strings in the grammar which can be parsed in two ways due to the
conflict. For example:
Example exp '+' exp • '/' exp
First derivation exp ::=[ exp ::=[ exp '+' exp • ] '/' exp ]
Second derivation exp ::=[ exp '+' exp ::=[ exp • '/' exp ] ]
This is a shift/reduce conflict caused by none of the operators having
precedence, so the example can be parsed in the two ways shown. When
bison cannot find an example that can be derived in two ways, it instead
generates two examples that are the same up until the dot:
First example expr • ID $end
First derivation $accept ::=[ s ::=[ a ::=[ expr • ] ID ] $end ]
Second example expr • ID ',' ID $end
Second derivation $accept ::=[ s ::=[ a ::=[ expr ::=[ expr • ID ',' ] ]
ID ] $end ]
In these cases, the parser usually doesn't have enough lookahead to
differentiate the two given examples.
The counterexamples are "focused": in a large grammar they do not
pollute the output with all the derivations from the start symbol,
rather they start on the "conflicted nonterminal".
*** File prefix mapping
Contributed by Joshua Watt.
Bison learned a new argument, `--file-prefix-map OLD=NEW`. Any file path
in the output (specifically `#line` directives and `#ifdef` header guards)
that begins with the prefix OLD will have it replaced with the prefix NEW,
similar to the `-ffile-prefix-map` in GCC. This option can be used to
make bison output reproducible.
** Changes
*** Relocatable installation
When installed to be relocatable (via `configure --enable-relocatable`),
bison will now also look for a relocated m4.
*** C++ file names
The `filename_type` %define variable was renamed `api.filename.type`.
Instead of
%define filename_type "symbol"
write
%define api.filename.type {symbol}
(Or let `bison --update` do it for you).
It now defaults to `const std::string` instead of `std::string`.
*** Deprecated %define variable names
The following variables have been renamed for consistency. Backward
compatibility is ensured, but upgrading is recommended.
filename_type -> api.filename.type
package -> api.package
*** Push parsers no longer clear their state when parsing is finished
Previously push-parsers cleared their state when parsing was finished (on
success and on failure). This made it impossible to check if there were
parse errors, since `yynerrs` was also reset. This can be especially
troublesome when used in autocompletion, since a parser with error
recovery would suggest (irrelevant) expected tokens even if there were
failure.
Now the parser state can be examined when parsing is finished. The parser
state is reset when starting a new parse.
** Bug fixes
*** Include the generated header (yacc.c)
Historically, when --defines was used, bison generated a header and pasted
an exact copy of it into the generated parser implementation file. Since
Bison 3.4 it is possible to specify that the header should be `#include`d,
and how. For instance
%define api.header.include {"parse.h"}
or
%define api.header.include {<parser/parse.h>}
Now api.header.include defaults to `"header-basename"`, as was intended in
Bison 3.4, where `header-basename` is the basename of the generated
header. This is disabled when the generated header is `y.tab.h`, to
comply with Automake's ylwrap.
*** String aliases are faithfully propagated
Bison used to interpret user strings (i.e., decoding backslash escapes)
when reading them, and to escape them (i.e., issue non-printable
characters as backslash escapes, taking the locale into account) when
outputting them. As a consequence non-ASCII strings (say in UTF-8) ended
up "ciphered" as sequences of backslash escapes. This happened not only
in the generated sources (where the compiler will reinterpret them), but
also in all the generated reports (text, xml, html, dot, etc.). Reports
were therefore not readable when string aliases were not pure ASCII.
Worse yet: the output depended on the user's locale.
Now Bison faithfully treats the string aliases exactly the way the user
spelled them. This fixes all the aforementioned problems. However, now,
string aliases semantically equivalent but syntactically different (e.g.,
"A", "\x41", "\101") are considered to be different.
*** Crash when generating IELR
An old, well hidden, bug in the generation of IELR parsers was fixed.
- Bison 3.6.90 released [beta],
Akim Demaille <=