Re: Bison 3.4.90 released [beta]

[Adrian Vogelsgesang]

Hi Akim,

I quickly upgraded Hyper (having a SQL grammar, similar to Postgres’ grammar)
to use Bison 3.4.90.
Things are looking good, our internal test cases are successful.
I did not go through all our tests, though, e.g. I did not check address 
sanitizer and friends.

I also tested LAC, and it works :)

> positions moved from unsigned (for line and column numbers) to int.
Yes, I ran into this. Our build was failing at first due to this.

…/Debug/codegen/hyper/cts/parser/combinedsql.ypp: In function ‘int 
yylex(hyper::astql::AST**, sqlparser::SQLParser::location_type*, 
hyper::SQLLexer&, hyper::ASTContainer&)’:
…/Debug/codegen/hyper/cts/parser/combinedsql.ypp:2504:79: error: narrowing 
conversion of ‘(unsigned int)(((((long int)token.hyper::SQLLexer::Token::begin) 
- ((long int)scannerBegin)) (ceiling /) 1) + 1)’ from ‘unsigned int’ to ‘int’ 
inside { } [-Werror=narrowing]
    
(*yyloc)=sqlparser::SQLParser::location_type{sqlparser::position{nullptr,1,static_cast<unsigned>(token.begin-scannerBegin+1)},sqlparser::position{nullptr,1,static_cast<unsigned>(token.end-scannerBegin+1)}};
                                                                               
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fortunately, it was easy to fix by changing the static_cast<unsigned> to 
static_cast<int>.
We are abusing the bison-provided location class to store byte-offsets here, so 
I guess this falls into the category of “breakage due to API abuse”.

Cheers,
Adrian



From: bison-patches <bison-patches-bounces+avogelsgesang=address@hidden> on 
behalf of Akim Demaille <address@hidden>
Reply-To: Bison Bugs <address@hidden>
Date: Wednesday, 30 October 2019 at 07:30
To: "address@hidden" <address@hidden>
Cc: Benno Schulenberg <address@hidden>, Bison Help <address@hidden>, Bison Bugs 
<address@hidden>, Bison Patches <address@hidden>
Subject: Bison 3.4.90 released [beta]

Dear Bison riders,

There is already quite a large number of patches since Bison 3.4:
265 so far (3.0: 1225, 3.1: 252, 3.2: 297, 3.3: 255, 3.4: 209). Many
of them are "invisible" and mostly related to refactoring and
preparing forthcoming changes. But some of them have a very visible
impact.

In particular the use of integral types has been revised in both the
generator and the generated parsers (thanks to Paul Eggert). As a
consequence small parsers have a smaller footprint, and very large
automata are now possible with the default backend (yacc.c).

There is one breaking change that somewhat worries me: in C++
positions moved from unsigned (for line and column numbers) to int.
It might break some existing projects, and maybe not. We *need* to
know! If it does break your project, then we will design some
migration path. Otherwise, let's keep things simple.

Please, torture this beta, and report your mileage!

Cheers!

==================================================================

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/<https://gnu.org/software/bison/>

==================================================================

Here are the compressed sources:
https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.gz<https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.gz>
 (4.1MB)
https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.xz<https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.xz>
 (3.1MB)

Here are the GPG detached signatures[*]:
https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.gz.sig<https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.gz.sig>
https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.xz.sig<https://alpha.gnu.org/gnu/bison/bison-3.4.90.tar.xz.sig>

Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html<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.4.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<http://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<http://0.19.8.1>
Gnulib v0.1-2899-g56ca994d4

==================================================================

NEWS

* Noteworthy changes in release 3.4.90 (2019-10-29) [beta]

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

** Bug fixes

In Java, %define api.prefix was ignored. It now behaves as expected.

** New features

*** Lookahead correction in C++

Contributed by Adrian Vogelsgesang.

The C++ deterministic skeleton (lalr1.cc<http://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.

*** Diagnostics with insertion

The diagnostics now display 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 …
| ^~~

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

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

*** 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).