Re: Bison 3.2.90 released [beta]

[Derek Clegg]

This is a more serious problem for me:

aux/parser-internal.h:767:7: error: instantiation of function
      'yy::parser::basic_symbol<yy::parser::by_type>::basic_symbol' required
      here, but no definition is available [-Werror,-Wundefined-func-template]
      symbol_type () {}
      ^
aux/parser-internal.h:530:7: note: forward declaration of template entity is
      here
      basic_symbol ();
      ^
aux/parser-internal.h:767:7: note: add an explicit instantiation declaration to
      suppress this warning if
      'yy::parser::basic_symbol<yy::parser::by_type>::basic_symbol' is
      explicitly instantiated in another translation unit
      symbol_type () {}
      ^
1 error generated.

I don’t know think it’s possible to declare a forward declaration of a template 
entity within a class, which makes the fix nontrivial. The only fix I can see 
is to move the definitions of the symbol_type methods outside of the header 
file and into the .cc file (which I think would be clearer, in any case).

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