[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.2.90 released [beta]
From: |
Derek Clegg |
Subject: |
Re: Bison 3.2.90 released [beta] |
Date: |
Sun, 13 Jan 2019 13:20:17 -0800 |
Hereβs another one:
aux/parser.cc:228:13: error: unannotated fall-through between switch labels
[-Werror,-Wimplicit-fallthrough]
default:
^
aux/parser.cc:228:13: note: insert '[[fallthrough]];' to silence this warning
default:
^
[[fallthrough]];
aux/parser.cc:228:13: note: insert 'break;' to avoid fall-through
default:
^
break;
1 error generated.
I fixed this like so:
diff -ur bison-3.2.90/data/skeletons/lalr1.cc bison/data/skeletons/lalr1.cc
--- bison-3.2.90/data/skeletons/lalr1.cc 2019-01-10 21:59:08.000000000 -\
0800
+++ bison/data/skeletons/lalr1.cc 2019-01-13 13:15:26.000000000 -0800
@@ -533,6 +533,11 @@
if (*++yyp != '\\')
goto do_not_strip_quotes;
// Fall through.
+#ifdef __has_feature
+#if __has_feature(cxx_attributes)
+ [[fallthrough]];
+#endif
+#endif
default:
yyr += *yyp;
break;
There may be a more canonical way to do this; I donβ know.
Thanks,
Derek
> On Jan 12, 2019, at 2:26 AM, Akim Demaille <address@hidden> wrote:
>
> We are very happy to announce the release of Bison 3.2.90, a beta of
> Bison 3.3. Please, use it, stress it, and report results.
>
> 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.
>
> 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.90.tar.gz (4.1MB)
> https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.xz (2.1MB)
>
> Here are the GPG detached signatures[*]:
> https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.gz.sig
> https://alpha.gnu.org/gnu/bison/bison-3.2.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.2.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.1
> Flex 2.6.4
> Gettext 0.19.8.1
> Gnulib v0.1-2353-g315eb5ffc
>
> NEWS
>
> * π 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