979d96298f
* Noteworthy changes in release 3.7.1 (2020-08-02) [stable]
** Bug fixes
Crash when a token alias contains a NUL byte.
Portability issues with libtextstyle.
Portability issues of Bison itself with MSVC.
** Changes
Improvements and fixes in the documentation.
More precise location about symbol type redefinitions.
* Noteworthy changes in release 3.7 (2020-07-23) [stable]
** 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 `-Wcounterexamples`/`-Wcex`, bison will now output
counterexamples for conflicts.
**** Unifying Counterexamples
Unifying counterexamples are strings which can be parsed in two ways due
to the conflict. For example on a grammar that contains the usual
"dangling else" ambiguity:
$ bison else.y
else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
else.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
$ bison else.y -Wcex
else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
else.y: warning: shift/reduce conflict on token "else" [-Wcounterexamples]
Example: "if" exp "then" "if" exp "then" exp • "else" exp
Shift derivation
exp
↳ "if" exp "then" exp
↳ "if" exp "then" exp • "else" exp
Example: "if" exp "then" "if" exp "then" exp • "else" exp
Reduce derivation
exp
↳ "if" exp "then" exp "else" exp
↳ "if" exp "then" exp •
When text styling is enabled, colors are used in the examples and the
derivations to highlight the structure of both analyses. In this case,
"if" exp "then" [ "if" exp "then" exp • ] "else" exp
vs.
"if" exp "then" [ "if" exp "then" exp • "else" exp ]
The counterexamples are "focused", in two different ways. First, they do
not clutter the output with all the derivations from the start symbol,
rather they start on the "conflicted nonterminal". They go straight to the
point. Second, they don't "expand" nonterminal symbols uselessly.
**** Nonunifying Counterexamples
In the case of the dangling else, Bison found an example that can be
parsed in two ways (therefore proving that the grammar is ambiguous).
When it cannot find such an example, it instead generates two examples
that are the same up until the dot:
$ bison foo.y
foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
foo.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
4 | a: expr
| ^~~~
$ bison -Wcex foo.y
foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
foo.y: warning: shift/reduce conflict on token ID [-Wcounterexamples]
First example: expr • ID ',' ID $end
Shift derivation
$accept
↳ s $end
↳ a ID
↳ expr
↳ expr • ID ','
Second example: expr • ID $end
Reduce derivation
$accept
↳ s $end
↳ a ID
↳ expr •
foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
4 | a: expr
| ^~~~
In these cases, the parser usually doesn't have enough lookahead to
differentiate the two given examples.
**** Reports
Counterexamples are also included in the report when given
`--report=counterexamples`/`-rcex` (or `--report=all`), with more
technical details:
State 7
1 exp: "if" exp "then" exp • [$end, "then", "else"]
2 | "if" exp "then" exp • "else" exp
"else" shift, and go to state 8
"else" [reduce using rule 1 (exp)]
$default reduce using rule 1 (exp)
shift/reduce conflict on token "else":
1 exp: "if" exp "then" exp •
2 exp: "if" exp "then" exp • "else" exp
Example: "if" exp "then" "if" exp "then" exp • "else" exp
Shift derivation
exp
↳ "if" exp "then" exp
↳ "if" exp "then" exp • "else" exp
Example: "if" exp "then" "if" exp "then" exp • "else" exp
Reduce derivation
exp
↳ "if" exp "then" exp "else" exp
↳ "if" exp "then" exp •
*** 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
*** Diagnostics
When text styling is enabled and the terminal supports it, the warnings
now include hyperlinks to the documentation.
*** 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.
** Documentation
*** Examples
The bistromathic demonstrates %param and how to quote sources in the error
messages:
> 123 456
1.5-7: syntax error: expected end of file or + or - or * or / or ^ before number
1 | 123 456
| ^~~
** 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.
* Noteworthy changes in release 3.6.4 (2020-06-15) [stable]
** Bug fixes
In glr.cc some internal macros leaked in the user's code, and could damage
access to the token kinds.
* Noteworthy changes in release 3.6.3 (2020-06-03) [stable]
** Bug fixes
Incorrect comments in the generated parsers.
Warnings in push parsers (yacc.c).
Incorrect display of gotos in LAC traces (lalr1.cc).
* Noteworthy changes in release 3.6.2 (2020-05-17) [stable]
** Bug fixes
Some tests were fixed.
When token aliases contain comment delimiters:
%token FOO "/* foo */"
bison used to emit "nested" comments, which is invalid C.
* Noteworthy changes in release 3.6.1 (2020-05-10) [stable]
** Bug fixes
Restored ANSI-C compliance in yacc.c.
GNU readline portability issues.
In C++, yy::parser::symbol_name is now a public member, as was intended.
** New features
In C++, yy::parser::symbol_type now has a public name() member function.
* Noteworthy changes in release 3.6 (2020-05-08) [stable]
** Backward incompatible changes
TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
The YYERROR_VERBOSE macro is no longer supported; the parsers that still
depend on it will now produce Yacc-like error messages (just "syntax
error"). It was superseded by the "%error-verbose" directive in Bison
1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that support
for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
(2013-07-25), "%error-verbose" is deprecated in favor of "%define
parse.error verbose".
** 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
*** Improved syntax error messages
Two new values for the %define parse.error variable offer more control to
the user. Available in all the skeletons (C, C++, Java).
**** %define parse.error detailed
The behavior of "%define parse.error detailed" is closely resembling that
of "%define parse.error verbose" with a few exceptions. First, it is safe
to use non-ASCII characters in token aliases (with 'verbose', the result
depends on the locale with which bison was run). Second, a yysymbol_name
function is exposed to the user, instead of the yytnamerr function and the
yytname table. Third, token internationalization is supported (see
below).
**** %define parse.error custom
With this directive, the user forges and emits the syntax error message
herself by defining the yyreport_syntax_error function. A new type,
yypcontext_t, captures the circumstances of the error, and provides the
user with functions to get details, such as yypcontext_expected_tokens to
get the list of expected token kinds.
A possible implementation of yyreport_syntax_error is:
int
yyreport_syntax_error (const yypcontext_t *ctx)
{
int res = 0;
YY_LOCATION_PRINT (stderr, *yypcontext_location (ctx));
fprintf (stderr, ": syntax error");
// Report the tokens expected at this point.
{
enum { TOKENMAX = 10 };
yysymbol_kind_t expected[TOKENMAX];
int n = yypcontext_expected_tokens (ctx, expected, TOKENMAX);
if (n < 0)
// Forward errors to yyparse.
res = n;
else
for (int i = 0; i < n; ++i)
fprintf (stderr, "%s %s",
i == 0 ? ": expected" : " or", yysymbol_name (expected[i]));
}
// Report the unexpected token.
{
yysymbol_kind_t lookahead = yypcontext_token (ctx);
if (lookahead != YYSYMBOL_YYEMPTY)
fprintf (stderr, " before %s", yysymbol_name (lookahead));
}
fprintf (stderr, "\n");
return res;
}
**** Token aliases internationalization
When the %define variable parse.error is set to `custom` or `detailed`,
one may specify which token aliases are to be translated using _(). For
instance
%token
PLUS "+"
MINUS "-"
<double>
NUM _("number")
<symrec*>
FUN _("function")
VAR _("variable")
In that case the user must define _() and N_(), and yysymbol_name returns
the translated symbol (i.e., it returns '_("variable")' rather that
'"variable"'). In Java, the user must provide an i18n() function.
*** List of expected tokens (yacc.c)
Push parsers may invoke yypstate_expected_tokens at any point during
parsing (including even before submitting the first token) to get the list
of possible tokens. This feature can be used to propose autocompletion
(see below the "bistromathic" example).
It makes little sense to use this feature without enabling LAC (lookahead
correction).
*** Returning the error token
When the scanner returns an invalid token or the undefined token
(YYUNDEF), the parser generates an error message and enters error
recovery. Because of that error message, most scanners that find lexical
errors generate an error message, and then ignore the invalid input
without entering the error-recovery.
The scanners may now return YYerror, the error token, to enter the
error-recovery mode without triggering an additional error message. See
the bistromathic for an example.
*** Deep overhaul of the symbol and token kinds
To avoid the confusion with types in programming languages, we now refer
to token and symbol "kinds" instead of token and symbol "types". The
documentation and error messages have been revised.
All the skeletons have been updated to use dedicated enum types rather
than integral types. Special symbols are now regular citizens, instead of
being declared in ad hoc ways.
**** Token kinds
The "token kind" is what is returned by the scanner, e.g., PLUS, NUMBER,
LPAREN, etc. While backward compatibility is of course ensured, users are
nonetheless invited to replace their uses of "enum yytokentype" by
"yytoken_kind_t".
This type now also includes tokens that were previously hidden: YYEOF (end
of input), YYUNDEF (undefined token), and YYerror (error token). They
now have string aliases, internationalized when internationalization is
enabled. Therefore, by default, error messages now refer to "end of file"
(internationalized) rather than the cryptic "$end", or to "invalid token"
rather than "$undefined".
Therefore in most cases it is now useless to define the end-of-line token
as follows:
%token T_EOF 0 "end of file"
Rather simply use "YYEOF" in your scanner.
**** Symbol kinds
The "symbol kinds" is what the parser actually uses. (Unless the
api.token.raw %define variable is used, the symbol kind of a terminal
differs from the corresponding token kind.)
They are now exposed as a enum, "yysymbol_kind_t".
This allows users to tailor the error messages the way they want, or to
process some symbols in a specific way in autocompletion (see the
bistromathic example below).
*** Modernize display of explanatory statements in diagnostics
Since Bison 2.7, output was indented four spaces for explanatory
statements. For example:
input.y:2.7-13: error: %type redeclaration for exp
input.y:1.7-11: previous declaration
Since the introduction of caret-diagnostics, it became less clear. This
indentation has been removed and submessages are displayed similarly as in
GCC:
input.y:2.7-13: error: %type redeclaration for exp
2 | %type <float> exp
| ^~~~~~~
input.y:1.7-11: note: previous declaration
1 | %type <int> exp
| ^~~~~
Contributed by Victor Morales Cayuela.
*** C++
The token and symbol kinds are yy::parser::token_kind_type and
yy::parser::symbol_kind_type.
The symbol_type::kind() member function allows to get the kind of a
symbol. This can be used to write unit tests for scanners, e.g.,
yy::parser::symbol_type t = make_NUMBER ("123");
assert (t.kind () == yy::parser::symbol_kind::S_NUMBER);
assert (t.value.as<int> () == 123);
** Documentation
*** User Manual
In order to avoid ambiguities with "type" as in "typing", we now refer to
the "token kind" (e.g., `PLUS`, `NUMBER`, etc.) rather than the "token
type". We now also refer to the "symbol type" (e.g., `PLUS`, `expr`,
etc.).
*** Examples
There are now examples/java: a very simple calculator, and a more complete
one (push-parser, location tracking, and debug traces).
The lexcalc example (a simple example in C based on Flex and Bison) now
also demonstrates location tracking.
A new C example, bistromathic, is a fully featured interactive calculator
using many Bison features: pure interface, push parser, autocompletion
based on the current parser state (using yypstate_expected_tokens),
location tracking, internationalized custom error messages, lookahead
correction, rich debug traces, etc.
It shows how to depend on the symbol kinds to tailor autocompletion. For
instance it recognizes the symbol kind "VARIABLE" to propose
autocompletion on the existing variables, rather than of the word
"variable".
* Noteworthy changes in release 3.5.4 (2020-04-05) [stable]
** WARNING: Future backward-incompatibilities!
TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
Bison 3.6 will no longer support the YYERROR_VERBOSE macro; the parsers
that still depend on it will produce Yacc-like error messages (just
"syntax error"). It was superseded by the "%error-verbose" directive in
Bison 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that
support for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
(2013-07-25), "%error-verbose" is deprecated in favor of "%define
parse.error verbose".
** Bug fixes
Fix portability issues of the package itself on old compilers.
Fix api.token.raw support in Java.
* Noteworthy changes in release 3.5.3 (2020-03-08) [stable]
** Bug fixes
Error messages could quote lines containing zero-width characters (such as
\005) with incorrect styling. Fixes for similar issues with unexpectedly
short lines (e.g., the file was changed between parsing and diagnosing).
Several unlikely crashes found by fuzzing have been fixed.
* Noteworthy changes in release 3.5.2 (2020-02-13) [stable]
** Bug fixes
Portability issues and minor cosmetic issues.
The lalr1.cc skeleton properly rejects unsupported values for parse.lac
(as yacc.c does).
* Noteworthy changes in release 3.5.1 (2020-01-19) [stable]
** Bug fixes
Portability fixes.
Fix compiler warnings.
* 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 saves one table lookup per token, and also saves
the generation of the mapping table.
The gain is typically moderate, but in extreme cases (very simple user
actions), a 10% improvement can be observed.
*** Generated parsers use better types for states
Stacks now use the best integral type for state numbers, instead of always
using 15 bits. As a result "small" parsers now have a smaller memory
footprint (they use 8 bits), and there is support for large automata (16
bits), and extra large (using int, i.e., typically 31 bits).
*** Generated parsers prefer signed integer types
Bison skeletons now prefer signed to unsigned integer types when either
will do, as the signed types are less error-prone and allow for better
checking with 'gcc -fsanitize=undefined'. Also, the types chosen are now
portable to unusual machines where char, short and int are all the same
width. On non-GNU platforms this may entail including <limits.h> and (if
available) <stdint.h> to define integer types and constants.
*** A skeleton for the D programming language
For the last few releases, Bison has shipped a stealth experimental
skeleton: lalr1.d. It was first contributed by Oliver Mangold, based on
Paolo Bonzini's lalr1.java, and was cleaned and improved thanks to
H. S. Teoh.
However, because nobody has committed to improving, testing, and
documenting this skeleton, it is not clear that it will be supported in
the future.
The lalr1.d skeleton *is functional*, and works well, as demonstrated in
examples/d/calc.d. Please try it, enjoy it, and... commit to support it.
*** Debug traces in Java
The Java backend no longer emits code and data for parser tracing if the
%define variable parse.trace is not defined.
** Diagnostics
*** New diagnostic: -Wdangling-alias
String literals, which allow for better error messages, are (too)
liberally accepted by Bison, which might result in silent errors. For
instance
%type <exVal> cond "condition"
does not define "condition" as a string alias to 'cond' (nonterminal
symbols do not have string aliases). It is rather equivalent to
%nterm <exVal> cond
%token <exVal> "condition"
i.e., it gives the type 'exVal' to the "condition" token, which was
clearly not the intention.
Also, because string aliases need not be defined, typos such as "baz"
instead of "bar" will be not reported.
The option -Wdangling-alias catches these situations. On
%token BAR "bar"
%type <ival> foo "foo"
%%
foo: "baz" {}
bison -Wdangling-alias reports
warning: string literal not attached to a symbol
| %type <ival> foo "foo"
| ^~~~~
warning: string literal not attached to a symbol
| foo: "baz" {}
| ^~~~~
The -Wall option does not (yet?) include -Wdangling-alias.
*** Better POSIX Yacc compatibility diagnostics
POSIX Yacc restricts %type to nonterminals. This is now diagnosed by
-Wyacc.
%token TOKEN1
%type <ival> TOKEN1 TOKEN2 't'
%token TOKEN2
%%
expr:
gives with -Wyacc
input.y:2.15-20: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
2 | %type <ival> TOKEN1 TOKEN2 't'
| ^~~~~~
input.y:2.29-31: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
2 | %type <ival> TOKEN1 TOKEN2 't'
| ^~~
input.y:2.22-27: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
2 | %type <ival> TOKEN1 TOKEN2 't'
| ^~~~~~
*** Diagnostics with insertion
The diagnostics now display the suggestion below the underlined source.
Replacement for undeclared symbols are now also suggested.
$ cat /tmp/foo.y
%%
list: lis '.' |
$ bison -Wall foo.y
foo.y:2.7-9: error: symbol 'lis' is used, but is not defined as a token and has no rules; did you mean 'list'?
2 | list: lis '.' |
| ^~~
| list
foo.y:2.16: warning: empty rule without %empty [-Wempty-rule]
2 | list: lis '.' |
| ^
| %empty
foo.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
*** Diagnostics about long lines
Quoted sources may now be truncated to fit the screen. For instance, on a
30-column wide terminal:
$ cat foo.y
%token FOO FOO FOO
%%
exp: FOO
$ bison foo.y
foo.y:1.34-36: warning: symbol FOO redeclared [-Wother]
1 | … FOO …
| ^~~
foo.y:1.8-10: previous declaration
1 | %token FOO …
| ^~~
foo.y:1.62-64: warning: symbol FOO redeclared [-Wother]
1 | … FOO
| ^~~
foo.y:1.8-10: previous declaration
1 | %token FOO …
| ^~~
** Changes
*** Debugging glr.c and glr.cc
The glr.c skeleton always had asserts to check its own behavior (not the
user's). These assertions are now under the control of the parse.assert
%define variable (disabled by default).
*** Clean up
Several new compiler warnings in the generated output have been avoided.
Some unused features are no longer emitted. Cleaner generated code in
general.
** Bug Fixes
Portability issues in the test suite.
In theory, parsers using %nonassoc could crash when reporting verbose
error messages. This unlikely bug has been fixed.
In Java, %define api.prefix was ignored. It now behaves as expected.
8 lines
533 B
Text
8 lines
533 B
Text
$NetBSD: distinfo,v 1.53 2020/08/24 07:50:19 wiz Exp $
|
|
|
|
SHA1 (bison-3.7.1.tar.xz) = 534c7ee46331ff1f1fc96a378fd6a9f6b322a242
|
|
RMD160 (bison-3.7.1.tar.xz) = 1f65ab9e6040f427f76e40b29230649ff24a94f4
|
|
SHA512 (bison-3.7.1.tar.xz) = 9c4097b6ff26e819be14a9d4ef39f6f259c04627cd305e11da8e67897a369b2bba5ce96bf19fa5f6088670e90a9c5bc5c45172f8f482252aeec546b285dd0797
|
|
Size (bison-3.7.1.tar.xz) = 2605940 bytes
|
|
SHA1 (patch-Makefile.in) = 5ddd993114f4c4d1ff16ff35e5b9541dd1427975
|
|
SHA1 (patch-lib_isnan.c) = 5b44fc6e2e97e36f91cd784bf3a38ad459fccdab
|