pkgsrc-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[pkgsrc/trunk]: pkgsrc/devel/bison bison: update to 3.2.4.

branches:  trunk
changeset: 319463:6a517c11476b
user:      wiz <>
date:      Wed Feb 13 20:05:14 2019 +0000

bison: update to 3.2.4.

* Noteworthy changes in release 3.2.4 (2018-12-24) [stable]

** Bug fixes

  Fix the move constructor of symbol_type.

  Always provide a copy constructor for symbol_type, even in modern C++.

* Noteworthy changes in release 3.2.3 (2018-12-18) [stable]

** Bug fixes

  Properly support token constructors in C++ with types that include commas
  (e.g., std::pair<int, int>).  A regression introduced in Bison 3.2.

* Noteworthy changes in release 3.2.2 (2018-11-21) [stable]

** Bug fixes

  C++ portability issues.

* Noteworthy changes in release 3.2.1 (2018-11-09) [stable]

** Bug fixes

  Several portability issues have been fixed in the build system, in the
  test suite, and in the generated parsers in C++.

* Noteworthy changes in release 3.2 (2018-10-29) [stable]

** Backward incompatible changes

  Support for DJGPP, which have been unmaintained and untested for years, is
  obsolete.  Unless there is activity to revive it, it will be removed.

** Changes

  %printers should use yyo rather than yyoutput to denote the output stream.

  Variant-based symbols in C++ should use emplace() rather than build().

  In C++ parsers, parser::operator() is now a synonym for the parser::parse.

** Documentation

  A new section, "A Simple C++ Example", is a tutorial for parsers in C++.

  A comment in the generated code now emphasizes that users should not
  depend upon non-documented implementation details, such as macros starting
  with YY_.

** New features

*** C++: Support for move semantics (

  The skeleton now fully supports C++ move semantics, while
  maintaining compatibility with C++98.  You may now store move-only types
  when using Bison's variants.  For instance:

    %code {
      #include <memory>
      #include <vector>

    %skeleton ""
    %define api.value.type variant


    %token <int> INT "int";
    %type <std::unique_ptr<int>> int;
    %type <std::vector<std::unique_ptr<int>>> list;

      %empty    {}
    | list int  { $$ = std::move($1); $$.emplace_back(std::move($2)); }

    int: "int"  { $$ = std::make_unique<int>($1); }

*** C++: Implicit move of right-hand side values (

  In modern C++ (C++11 and later), you should always use 'std::move' with
  the values of the right-hand side symbols ($1, $2, etc.), as they will be
  popped from the stack anyway.  Using 'std::move' is mandatory for
  move-only types such as unique_ptr, and it provides a significant speedup
  for large types such as std::string, or std::vector, etc.

  If '%define api.value.automove' is set, every occurrence '$n' is replaced
  by 'std::move ($n)'.  The second rule in the previous grammar can be
  simplified to:

    list: list int  { $$ = $1; $$.emplace_back($2); }

  With automove enabled, the semantic values are no longer lvalues, so do
  not use the swap idiom:

    list: list int  { std::swap($$, $1); $$.emplace_back($2); }

  This idiom is anyway obsolete: it is preferable to move than to swap.

  A warning is issued when automove is enabled, and a value is used several

    input.yy:16.31-32: warning: multiple occurrences of $2 with api.value.automove enabled [-Wother]
    exp: "twice" exp   { $$ = $2 + $2; }

  Enabling api.value.automove does not require support for modern C++.  The
  generated code is valid C++98/03, but will use copies instead of moves.

  The new examples/c++/variant-11.yy shows these features in action.

*** C++: The implicit default semantic action is always run

  When variants are enabled, the default action was not run, so

    exp: "number"

  was equivalent to

    exp: "number"  {}

  It now behaves like in all the other cases, as

    exp: "number"  { $$ = $1; }

  possibly using std::move if automove is enabled.

  We do not expect backward compatibility issues.  However, beware of
  forward compatibility issues: if you rely on default actions with
  variants, be sure to '%require "3.2"' to avoid older versions of Bison to
  generate incorrect parsers.

*** C++: Renaming location.hh

  When both %defines and %locations are enabled, Bison generates a
  location.hh file.  If you don't use locations outside of the parser, you
  may avoid its creation with:

    %define api.location.file none

  However this file is useful if, for instance, your parser builds an AST
  decorated with locations: you may use Bison's location independently of
  Bison's parser.  You can now give it another name, for instance:

    %define api.location.file "my-location.hh"

  This name can have directory components, and even be absolute.  The name
  under which the location file is included is controlled by

  This way it is possible to have several parsers share the same location

  For instance, in src/foo/parser.hh, generate the include/ast/loc.hh file:

    %define api.namespace {foo}
    %define api.location.file "include/ast/loc.hh"
    %define api.location.include {<ast/loc.hh>}

  and use it in src/bar/parser.hh:

    %define api.namespace {bar}
    %code requires {#include <ast/loc.hh>}
    %define api.location.type {bar::location}

  Absolute file names are supported, so in your Makefile, passing the flag
  -Dapi.location.file='"$(top_srcdir)/include/ast/location.hh"' to bison is

*** C++: stack.hh and position.hh are deprecated

  When asked to generate a header file (%defines), the skeleton
  generates a stack.hh file.  This file had no interest for users; it is now
  made useless: its content is included in the parser definition.  It is
  still generated for backward compatibility.

  When in addition to %defines, location support is requested (%locations),
  the file position.hh is also generated.  It is now also useless: its
  content is now included in location.hh.

  These files are no longer generated when your grammar file requires at
  least Bison 3.2 (%require "3.2").

** Bug fixes

  Portability issues on MinGW and VS2015.

  Portability issues in the test suite.

  Portability/warning issues with Flex.

* Noteworthy changes in release 3.1 (2018-08-27) [stable]

** Backward incompatible changes

  Compiling Bison now requires a C99 compiler---as announced during the
  release of Bison 3.0, five years ago.  Generated parsers do not require a
  C99 compiler.

  Support for DJGPP, which have been unmaintained and untested for years, is
  obsolete. Unless there is activity to revive it, the next release of Bison
  will have it removed.

** New features

*** Typed midrule actions

  Because their type is unknown to Bison, the values of midrule actions are
  not treated like the others: they don't have %printer and %destructor
  support.  It also prevents C++ (Bison) variants to handle them properly.

  Typed midrule actions address these issues.  Instead of:

    exp: { $<ival>$ = 1; } { $<ival>$ = 2; }   { $$ = $<ival>1 + $<ival>2; }


    exp: <ival>{ $$ = 1; } <ival>{ $$ = 2; }   { $$ = $1 + $2; }

*** Reports include the type of the symbols

  The sections about terminal and nonterminal symbols of the '*.output' file
  now specify their declared type.  For instance, for:

    %token <ival> NUM

  the report now shows '<ival>':

    Terminals, with rules where they appear

    NUM <ival> (258) 5

*** Diagnostics about useless rules

  In the following grammar, the 'exp' nonterminal is trivially useless.  So,
  of course, its rules are useless too.

    input: '0' | exp
    exp: exp '+' exp | exp '-' exp | '(' exp ')'

  Previously all the useless rules were reported, including those whose
  left-hand side is the 'exp' nonterminal:

    warning: 1 nonterminal useless in grammar [-Wother]
    warning: 4 rules useless in grammar [-Wother]
    2.14-16: warning: nonterminal useless in grammar: exp [-Wother]
     input: '0' | exp
    2.14-16: warning: rule useless in grammar [-Wother]
     input: '0' | exp
    3.6-16: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
    3.20-30: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
    3.34-44: warning: rule useless in grammar [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'

  Now, rules whose left-hand side symbol is useless are no longer reported
  as useless.  The locations of the errors have also been adjusted to point
  to the first use of the nonterminal as a left-hand side of a rule:

    warning: 1 nonterminal useless in grammar [-Wother]
    warning: 4 rules useless in grammar [-Wother]
    3.1-3: warning: nonterminal useless in grammar: exp [-Wother]
     exp: exp '+' exp | exp '-' exp | '(' exp ')'
    2.14-16: warning: rule useless in grammar [-Wother]
     input: '0' | exp

*** C++: Generated parsers can be compiled with -fno-exceptions (

  When compiled with exceptions disabled, the generated parsers no longer
  uses try/catch clauses.

  Currently only GCC and Clang are supported.

** Documentation

*** A demonstration of variants

  A new example was added (installed in .../share/doc/bison/examples),
  'variant.yy', which shows how to use (Bison) variants in C++.

  The other examples were made nicer to read.

*** Some features are no longer 'experimental'

  The following features, mature enough, are no longer flagged as
  experimental in the documentation: push parsers, default %printer and
  %destructor (typed: <*> and untyped: <>), %define api.value.type union and
  variant, Java parsers, XML output, LR family (lr, ielr, lalr), and
  semantic predicates (%?).

** Bug fixes

*** GLR: Predicates support broken by #line directives

  Predicates (%?) in GLR such as

      %? {new_syntax} 'w' id new_args
    | %?{!new_syntax} 'w' id old_args

  were issued with #lines in the middle of C code.

*** Printer and destructor with broken #line directives

  The #line directives were not properly escaped when emitting the code for
  %printer/%destructor, which resulted in compiler errors if there are
  backslashes or double-quotes in the grammar file name.

*** Portability on ICC

  The Intel compiler claims compatibility with GCC, yet rejects its _Pragma.
  Generated parsers now work around this.

*** Various

  There were several small fixes in the test suite and in the build system,
  many warnings in bison and in the generated parsers were eliminated.  The
  documentation also received its share of minor improvements.

  Useless code was removed from C++ parsers, and some of the generated
  constructors are more 'natural'.


 devel/bison/Makefile                 |   4 ++--
 devel/bison/PLIST                    |  18 +++++++++++++-----
 devel/bison/distinfo                 |  11 +++++------
 devel/bison/patches/patch-data_glr.c |  25 -------------------------
 4 files changed, 20 insertions(+), 38 deletions(-)

diffs (91 lines):

diff -r 2e17e9ea2728 -r 6a517c11476b devel/bison/Makefile
--- a/devel/bison/Makefile      Wed Feb 13 20:00:59 2019 +0000
+++ b/devel/bison/Makefile      Wed Feb 13 20:05:14 2019 +0000
@@ -1,6 +1,6 @@
-# $NetBSD: Makefile,v 1.105 2019/01/22 03:20:40 ryoon Exp $
+# $NetBSD: Makefile,v 1.106 2019/02/13 20:05:14 wiz Exp $
-DISTNAME=      bison-3.0.5
+DISTNAME=      bison-3.2.4
 CATEGORIES=    devel
 EXTRACT_SUFX=  .tar.xz
diff -r 2e17e9ea2728 -r 6a517c11476b devel/bison/PLIST
--- a/devel/bison/PLIST Wed Feb 13 20:00:59 2019 +0000
+++ b/devel/bison/PLIST Wed Feb 13 20:05:14 2019 +0000
@@ -1,4 +1,4 @@
-@comment $NetBSD: PLIST,v 1.29 2019/01/22 03:20:40 ryoon Exp $
+@comment $NetBSD: PLIST,v 1.30 2019/02/13 20:05:14 wiz Exp $
@@ -32,11 +32,19 @@
diff -r 2e17e9ea2728 -r 6a517c11476b devel/bison/distinfo
--- a/devel/bison/distinfo      Wed Feb 13 20:00:59 2019 +0000
+++ b/devel/bison/distinfo      Wed Feb 13 20:05:14 2019 +0000
@@ -1,8 +1,7 @@
-$NetBSD: distinfo,v 1.49 2019/01/22 03:20:40 ryoon Exp $
+$NetBSD: distinfo,v 1.50 2019/02/13 20:05:14 wiz Exp $
-SHA1 (bison-3.0.5.tar.xz) = 45e904d04d88c821df95833c4be4414ce5a47a4b
-RMD160 (bison-3.0.5.tar.xz) = f13012d77dfddc8c5ed0c717f9006049ae17b8af
-SHA512 (bison-3.0.5.tar.xz) = 00b448db8abe91b07e32ff5273c6617bc1350d806f92073a9472f4c2f0de5d22c152795674171b74f2eb9eff8d36f8173b82dacb215601bb071ae39404d4a8a2
-Size (bison-3.0.5.tar.xz) = 1954868 bytes
-SHA1 (patch-data_glr.c) = a2e0900ed995e4320e80f8ed05eae8e82be50502
+SHA1 (bison-3.2.4.tar.xz) = 950c7fa571677828eab963126b93a4ed9d496b74
+RMD160 (bison-3.2.4.tar.xz) = 901b1c5357009604983d002c55d48d09ab750884
+SHA512 (bison-3.2.4.tar.xz) = 652b54fdee969bbc17eeb04d05d65f143e8e0e1b46ac2574e3a76687b9bd916c9a0c97658b4f8357958d64e87fe2a6a2a98a6c312970f0e74fb4445962e9daae
+Size (bison-3.2.4.tar.xz) = 2094568 bytes
 SHA1 (patch-lib_isnan.c) = 5b44fc6e2e97e36f91cd784bf3a38ad459fccdab
diff -r 2e17e9ea2728 -r 6a517c11476b devel/bison/patches/patch-data_glr.c
--- a/devel/bison/patches/patch-data_glr.c      Wed Feb 13 20:00:59 2019 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,25 +0,0 @@
-$NetBSD: patch-data_glr.c,v 1.1 2015/01/16 19:34:44 rumko Exp $
-Fixes "error: an attribute list cannot appear here" on fbsd
-under clang
---- data/glr.c.orig    2013-11-14 15:01:22.000000000 +0000
-+++ data/glr.c
-@@ -669,7 +669,7 @@ struct yyGLRStack {
- static void yyexpandGLRStack (yyGLRStack* yystackp);
- #endif
--static _Noreturn void
-+_Noreturn static void
- yyFail (yyGLRStack* yystackp]b4_pure_formals[, const char* yymsg)
- {
-   if (yymsg != YY_NULLPTR)
-@@ -677,7 +677,7 @@ yyFail (yyGLRStack* yystackp]b4_pure_for
-   YYLONGJMP (yystackp->yyexception_buffer, 1);
- }
--static _Noreturn void
-+_Noreturn static void
- yyMemoryExhausted (yyGLRStack* yystackp)
- {
-   YYLONGJMP (yystackp->yyexception_buffer, 2);

Home | Main Index | Thread Index | Old Index