[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.2.91 released [beta]
From: |
Derek Clegg |
Subject: |
Re: Bison 3.2.91 released [beta] |
Date: |
Sat, 19 Jan 2019 11:47:11 -0800 |
I ran into just one issue:
aux/parser-internal.h:429:12: error: 'syntax_error' has no out-of-line virtual
method definitions; its vtable will be emitted in every translation unit
[-Werror,-Wweak-vtables]
struct syntax_error : std::runtime_error
^
1 error generated.
I fixed it this way:
diff -ur bison-3.2.91/data/skeletons/c++.m4 bison/data/skeletons/c++.m4
--- bison-3.2.91/data/skeletons/c++.m4 2019-01-14 22:10:03.000000000 -0800
+++ bison/data/skeletons/c++.m4 2019-01-19 08:43:35.000000000 -0800
@@ -217,7 +217,9 @@
syntax_error (]b4_locations_if([const location_type& l, ])[const
std::string& m)
: std::runtime_error (m)]b4_locations_if([
, location (l)])[
- {}]b4_locations_if([
+ {}
+
+ virtual ~syntax_error();]b4_locations_if([
location_type location;])[
};
@@ -541,6 +543,9 @@
else
return undef_token_;
}
+
+ ]b4_parser_class[::syntax_error::~syntax_error()
+ {}
]])
Other than that, no problems. Thanks!
Derek
> On Jan 18, 2019, at 11:02 PM, Akim Demaille <address@hidden> wrote:
>
> We are very happy to announce the release of Bison 3.2.91, a beta of Bison
> 3.3. Please, use it, stress it, and report results.
>
> Compared to 3.2.90, several warnings have been addressed, and bison now
> helps updating grammar files: the option -ffixit issues editing directives
> for IDEs/editors, and the option --update immediately applies them the
> grammar file.
>
> It is now possible to annotate rules with their number of expected
> conflicts. Bison can be made relocatable. The symbol declaration syntax
> was overhauled, and in particular, %nterm, that exists since the origins of
> Bison, is now an officially supported (and documented!) feature. C++
> parsers now feature genuine symbol constructors, and use noexcept/constexpr.
> The GLR parsers in C++ now also support the syntax_error exceptions. There
> are also many smaller improvements, including a fix for a bug which is at
> least 31 years old.
>
> There's a also a stealth new feature that I don't plan to announce in the
> actual release of Bison 3.3: a backend for D, lalr1.d. This skeleton is
> experimental. It has several shortcomings that must be addressed before
> becoming a genuine part of GNU Bison. We expect the D community to
> contribute fixes/updates.
>
> Please see the NEWS below for more details.
>
> ==================================================================
>
> 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
> ought to 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 or C++
> programming in order to use Bison. Java is also supported.
>
> Here is the GNU Bison home page:
> https://gnu.org/software/bison/
>
> ==================================================================
>
> Here are the compressed sources:
> https://alpha.gnu.org/gnu/bison/bison-3.2.91.tar.gz (4.1MB)
> https://alpha.gnu.org/gnu/bison/bison-3.2.91.tar.xz (2.1MB)
>
> Here are the GPG detached signatures[*]:
> https://alpha.gnu.org/gnu/bison/bison-3.2.91.tar.gz.sig
> https://alpha.gnu.org/gnu/bison/bison-3.2.91.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.2.91.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-2353-g315eb5ffc
>
> NEWS
>
> * 🎉 Noteworthy changes in release 3.2.91 (2019-01-19) [beta]
>
> ** ✨ New features
>
> *** 📝 Generation of fix-its for IDEs/Editors
>
> When given the new option -ffixit (aka -fdiagnostics-parseable-fixits),
> bison now generates machine readable editing instructions to fix some
> issues. Currently, this is mostly limited to updating deprecated
> directives and removing duplicates. For instance:
>
> $ cat foo.y
> %error-verbose
> %define parser_class_name "Parser"
> %define api.parser.class "Parser"
> %%
> exp:;
>
> See the "fix-it:" lines below:
>
> $ bison -ffixit foo.y
> foo.y:1.1-14: warning: deprecated directive, use '%define parse.error
> verbose' [-Wdeprecated]
> %error-verbose
> ^~~~~~~~~~~~~~
> fix-it:"foo.y":{1:1-1:15}:"%define parse.error verbose"
> foo.y:2.1-34: warning: deprecated directive, use '%define api.parser.class
> {Parser}' [-Wdeprecated]
> %define parser_class_name "Parser"
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> fix-it:"foo.y":{2:1-2:35}:"%define api.parser.class {Parser}"
> foo.y:3.1-33: error: %define variable 'api.parser.class' redefined
> %define api.parser.class "Parser"
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> foo.y:2.1-34: previous definition
> %define parser_class_name "Parser"
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> fix-it:"foo.y":{3:1-3:34}:""
> foo.y: warning: fix-its can be applied. Rerun with option '--update'.
> [-Wother]
>
> This uses the same output format as GCC and Clang.
>
> *** ✂️ Updating grammar files
>
> Fixes can be applied on the fly. The previous example ends with the
> suggestion to re-run bison with the option -u/--update, which results in a
> cleaner grammar file.
>
> $ bison --update foo.y
> [...]
> bison: file 'foo.y' was updated (backup: 'foo.y~')
>
> $ cat foo.y
> %define parse.error verbose
> %define api.parser.class {Parser}
> %%
> exp:;
>
> * 🎉 Noteworthy changes in release 3.2.90 (2019-01-12) [beta]
>
> ** ☠️ Backward incompatible changes
>
> Support for DJGPP, which has been unmaintained and untested for years, is
> removed.
>
> ** ⚰️️ Deprecated features
>
> The %error-verbose directive is deprecated in favor of '%define
> parse.error verbose' since Bison 3.0, but no warning was issued.
>
> The '%name-prefix "xx"' directive is deprecated in favor of '%define
> api.prefix {xx}' since Bison 3.0, but no warning was issued. These
> directives are slightly different, you might need to adjust your code.
> %name-prefix renames only symbols with external linkage, while api.prefix
> also renames types and macros, including @code{YYDEBUG},
> @code{YYTOKENTYPE}, @code{yytokentype}, @code{YYSTYPE}, @code{YYLTYPE},
> etc.
>
> The following variables, mostly related to parsers in Java, have been
> renamed for consistency. Backward compatibility is ensured, but upgrading
> is recommended.
>
> abstract -> api.parser.abstract
> annotations -> api.parser.annotations
> extends -> api.parser.extends
> final -> api.parser.final
> implements -> api.parser.implements
> parser_class_name -> api.parser.class
> public -> api.parser.public
> strictfp -> api.parser.strictfp
>
> ** ✨ New features
>
> *** ✨ Bison is now relocatable
>
> If you pass '--enable-relocatable' to 'configure', Bison is relocatable.
>
> A relocatable program can be moved or copied to a different location on
> the file system. It can also be used through mount points for network
> sharing. It is possible to make symlinks to the installed and moved
> programs, and invoke them through the symlink.
>
> *** ✨ %expect and %expect-rr modifiers on individual rules
>
> One can now document (and check) which rules participate in shift/reduce
> and reduce/reduce conflicts. This is particularly important GLR parsers,
> where conflicts are a normal occurrence. For example,
>
> %glr-parser
> %expect 1
> %%
>
> ...
>
> argument_list:
> arguments %expect 1
> | arguments ','
> | %empty
> ;
>
> arguments:
> expression
> | argument_list ',' expression
> ;
>
> ...
>
> Looking at the output from -v, one can see that the shift-reduce conflict
> here is due to the fact that the parser does not know whether to reduce
> arguments to argument_list until it sees the token _after_ the following
> ','. By marking the rule with %expect 1 (because there is a conflict in
> one state), we document the source of the 1 overall shift-reduce conflict.
>
> In GLR parsers, we can use %expect-rr in a rule for reduce/reduce
> conflicts. In this case, we mark each of the conflicting rules. For
> example,
>
> %glr-parser
> %expect-rr 1
>
> %%
>
> stmt:
> target_list '=' expr ';'
> | expr_list ';'
> ;
>
> target_list:
> target
> | target ',' target_list
> ;
>
> target:
> ID %expect-rr 1
> ;
>
> expr_list:
> expr
> | expr ',' expr_list
> ;
>
> expr:
> ID %expect-rr 1
> | ...
> ;
>
> In a statement such as
>
> x, y = 3, 4;
>
> the parser must reduce x to a target or an expr, but does not know which
> until it sees the '='. So we notate the two possible reductions to
> indicate that each conflicts in one rule.
>
> This feature needs user feedback, and might evolve in the future.
>
> *** ✨ C++: Actual token constructors
>
> When variants and token constructors are enabled, in addition to the
> type-safe named token constructors (make_ID, amke_INT, etc.), we now
> generate genuine constructors for symbol_type.
>
> For instance with these declarations
>
> %token ':'
> <std::string> ID
> <int> INT;
>
> you may use these constructors:
>
> symbol_type (int token, const std::string&);
> symbol_type (int token, const int&);
> symbol_type (int token);
>
> which should be used in a Flex-scanner as follows.
>
> %%
> [a-z]+ return yy::parser::symbol_type (ID, yytext);
> [0-9]+ return yy::parser::symbol_type (INT, text_to_int (yytext);
> ":" return yy::parser::symbol_type (’:’);
> <<EOF>> return yy::parser::symbol_type (0);
>
> Correct matching between token types and value types is checked via
> 'assert'. For instance, 'symbol_type (ID, 42)' would abort (while
> 'make_ID (42)' would not even compile).
>
> *** ✨ C++: Variadic emplace
>
> If your application requires C++11 and you don't use symbol constructors,
> you may now use a variadic emplace for semantic values:
>
> %define api.value.type variant
> %token <std::pair<int, int>> PAIR
>
> in your scanner:
>
> int yylex (parser::semantic_type *lvalp)
> {
> lvalp->emplace <std::pair<int, int>> (1, 2);
> return parser::token::PAIR;
> }
>
> *** ✨ C++: Syntax error exceptions in GLR
>
> The glr.cc skeleton now supports syntax_error exceptions thrown from user
> actions, or from the scanner.
>
> *** 🚨 More POSIX Yacc compatibility warnings
>
> More Bison specific directives are now reported with -y or -Wyacc. This
> change was ready since the release of Bison 3.0 in September 2015. It was
> delayed because Autoconf used to define YACC as `bison -y`, which resulted
> in numerous warnings for Bison users that use the GNU Build System.
>
> If you still experience that problem, either redefine YACC as `bison -o
> y.tab.c`, or pass -Wno-yacc to Bison.
>
> *** 🧟♂️ The tables yyrhs and yyphrs are back
>
> Because no Bison skeleton uses them, these tables were removed (no longer
> passed to the skeletons, not even computed) in 2008. However, some users
> have expressed interest in being able to use them in their own skeletons.
>
> ** 🐛 Bug fixes
>
> *** Incorrect number of reduce-reduce conflicts
>
> On a grammar such as
>
> exp: "num" | "num" | "num"
>
> bison used to report a single RR conflict, instead of two. This is now
> fixed. This was the oldest (known) bug in Bison: it was there when Bison
> was entered in the RCS version control system, in December 1987.
>
> Some grammar files might have to adjust their %expect-rr.
>
> *** Parser directives that were not careful enough
>
> Passing invalid arguments to %nterm, for instance character literals, used
> to result in unclear error messages.
>
> ** 📚 Documentation
>
> The examples/ directory (installed in .../share/doc/bison/examples) has
> been restructured per language for clarity. The examples come with a
> README and a Makefile. Not only can they be used to toy with Bison, they
> can also be starting points for your own grammars.
>
> There is now a Java example, and a simple example in C based on Flex and
> Bison (examples/c/lexcalc/).
>
> ** 💰 Changes
>
> *** Parsers in C++
>
> They now use noexcept and constexpr. Please, report missing annotations.
>
> *** Symbol Declarations
>
> The syntax of the variation directives to declare symbols was overhauled
> for more consistency, and also better POSIX Yacc compliance (which, for
> instance, allows "%type" without actually providing a type). The %nterm
> directive, supported by Bison since its inception, is now documented and
> officially supported.
>
> The syntax is now as follows:
>
> %token TAG? ( ID NUMBER? STRING? )+ ( TAG ( ID NUMBER? STRING? )+ )*
> %left TAG? ( ID NUMBER? )+ ( TAG ( ID NUMBER? )+ )*
> %type TAG? ( ID | CHAR | STRING )+ ( TAG ( ID | CHAR | STRING )+ )*
> %nterm TAG? ID+ ( TAG ID+ )*
>
> where TAG denotes a type tag such as ‘<ival>’, ID denotes an identifier
> such as ‘NUM’, NUMBER a decimal or hexadecimal integer such as ‘300’ or
> ‘0x12d’, CHAR a character literal such as ‘'+'’, and STRING a string
> literal such as ‘"number"’. The postfix quantifiers are ‘?’ (zero or
> one), ‘*’ (zero or more) and ‘+’ (one or more).
>
>
>
> _______________________________________________
> address@hidden https://lists.gnu.org/mailman/listinfo/help-bison
Re: [Bison-Announce] Bison 3.2.91 released [beta], Frank Heckenbach, 2019/01/20