gmane.comp.parsers.bison.bugs

bison-2.5.1_rc2 released [beta]

Akim Demaille — 2012-05-25T17:19:31

The Bison team is very happy to announce the forthcoming release
of Bison 2.5.1, which addresses quite a few issues from Bison 2.5.

Here are the compressed sources:
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.gz   (2.7MB)
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.xz   (1.5MB)

Here are the GPG detached signatures[*]:
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.gz.sig
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.xz.sig

Use a mirror for higher download bandwidth:
 http://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-2.5.1_rc2.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 78D5264E

and rerun the 'gpg --verify' command.

This release was bootstrapped with the fol

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-21T12:50:59

Le 21 mai 2012 à 14:36, Stefano Lattarini a écrit :


Thanks, I installed the two attached patches in "maint".

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-21T12:36:36

Yes: 'next' bootstraps, builds and passes the testsuite.

Regards,
  Stefano

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-21T09:13:55

Le 19 mai 2012 à 15:41, Stefano Lattarini a écrit :


Ah, indeed.  I don't consider that bootstrap's job is
to play with the submodules, but it might help indeed.

And so, back to the Flex issue, does my proposal fix
the problem?

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-19T13:41:09

I had indeed done "git clean -fdx" before re-boostrapping.

I've tried from a freshly-cloned repository; same error.

But I've now found the problem: "bootstrap" doesn't initialize the
'autoconf' submodule!  If I do that manually:

    git submodule init && git submodule update

the bootstrap succeeds.

Regards,
  Stefano

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-16T09:07:22

Le 16 mai 2012 à 10:54, Stefano Lattarini a écrit :


Really, did you start from a fresh clone?  There are very nasty
issues, such as dangling symlink for *.m4 files that breaks
aclocal.  Be sure to, at least, git clean -fr.  Or just
rm -rf in your bison directory and check out again.

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-16T08:54:31

Sorry, I've been unclear; I meant: the *bootstrap* itself fails like this:


  Don't forget to
    - "include gnulib.mk" from within "lib/Makefile.am",
    - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
    - mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
    - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC_STDC,
    - invoke gl_INIT in ./configure.ac.
  running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install \
                                                     --no-recursive -I m4
  autoreconf2.50: Entering directory `.'
  autoreconf2.50: running: true
  autoreconf2.50: running: aclocal -I m4 -I m4
  autoreconf2.50: configure.ac: tracing
  autoreconf2.50: configure.ac: not using Libtool
  autoreconf2.50: running: /usr/bin/autoconf --include=m4
  configure.ac:122: error: possibly undefined macro: AC_PROG_GNU_M4
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
  autoreconf2.50: /usr/bin/autoconf fail

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-16T08:34:56

Le 15 mai 2012 à 22:45, Stefano Lattarini a écrit :


No :(  That's really weird.  Could you please provide me
with one of the wrong generated scanner?  Maybe there's
something wrong in the macros that define the version?

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-15T20:45:44

OK, I've re-done the check applying the patch to the top of maint, but I
see the same exact error as before.  Any clue?

Regards,
  Stefano

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-15T17:28:57

Le 15 mai 2012 à 18:19, Stefano Lattarini  
<stefano.lattarini< at >gmail.com> a écrit :


Next is on top of maint, and I guess you
had checked out master.  This is a case
where bootstrap behaves very badly and
you get all sorts of failures.

I should have told you this is not master,
sorry :/

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-15T16:19:04

And right after it has failed, I get:

  $ git diff
  diff --git a/m4/m4.m4 b/m4/m4.m4
  deleted file mode 120000
  index 5b176ba..0000000
  --- a/m4/m4.m4
  +++ /dev/null
  < at >< at > -1 +0,0 < at >< at >
  -../submodules/autoconf/m4/m4.m4
  \ No newline at end of file

Regards,
  Stefano

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-15T15:59:42

Bootstrapping the 'next' branch fails for me with:

  Don't forget to
    - "include gnulib.mk" from within "lib/Makefile.am",
    - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
    - mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
    - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC_STDC,
    - invoke gl_INIT in ./configure.ac.
  running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install \
                                                     --no-recursive -I m4
  autoreconf2.50: Entering directory `.'
  autoreconf2.50: running: true
  autoreconf2.50: running: aclocal -I m4 -I m4
  autoreconf2.50: configure.ac: tracing
  autoreconf2.50: configure.ac: not using Libtool
  autoreconf2.50: running: /usr/bin/autoconf --include=m4
  configure.ac:122: error: possibly undefined macro: AC_PROG_GNU_M4
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
  autoreconf2.50: /usr/bin/autoconf failed with exit status: 1

T

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-15T09:23:52

Le 14 mai 2012 à 23:11, Stefano Lattarini a écrit :


So I guess this is a modified 2.5.35, as I have:

int code_get_leng (void );

Great...



Could you please try the attached patch?  Also in the
branch "next" at the moment.

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-14T21:11:50

Basically, it was a version of flex built from its development branch.
But the error persists also with flex 2.5.35 (installed from a Debian
package).


From 'src/scan-code.c':

    220:typedef size_t yy_size_t;
    ...
    679:#define FLEX_PREFIX(Id) code_ ## Id
    680:#include <src/flex-scanner.h>
    ...
    789:yy_size_t code_get_leng (void );

From 'src/flex-scanner.h':

    28:int   FLEX_PREFIX (get_leng) (void);

HTH,
  Stefano

Re: Building bison from master fails: "conflicting types for'code_get_leng'"

Akim Demaille — 2012-05-14T12:01:10

Le 13 mai 2012 à 12:46, Stefano Lattarini a écrit :


Hi Stefano,

Thanks for the report.  As far as I know there is no
such things as Flex 2.5.36.  Where does it come from?
Could you provide me with the conflicted types?

Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-13T10:46:59

When I try to bootstrap and build bison from latest master on my Debian
system, I see this failure:

  ...
  CC       src/src_bison-reduce.o
  CC       src/src_bison-relation.o
  CC       src/src_bison-scan-code-c.o
In file included from src/scan-code-c.c:3:0:
src/scan-code.c:789:11: error: conflicting types for 'code_get_leng'
./src/flex-scanner.h:28:1: note: previous declaration of 'code_get_leng' was here
In file included from src/scan-code-c.c:3:0:
src/scan-code.c:2344:11: error: conflicting types for 'code_get_leng'
./src/flex-scanner.h:28:1: note: previous declaration of 'code_get_leng' was here
Makefile:3833: recipe for target 'src/src_bison-scan-code-c.o' failed
make[2]: *** [src/src_bison-scan-code-c.o] Error 1

Attached is the config.log.  I'm using Automake and Autoconf from master, and
flex 2.5.36.  Let me know if you need more information.

Regards,
  Stefano

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-09T08:02:16

Le 6 mai 2012 à 11:27, Jim Meyering a écrit :


And I guess the git rebase has restored younger mtimes
to the generated files after you modified the source one.


Why not.  I kinda like the current setting, which avoids commits
which just change minor things (say the version of the bison
version that was used) in the generated files by leaving this in
the hands of the maintainers.  So if we find a means to avoid
gratuitous commits, I'm fine with this.

Bison uses itself to compile itself, via the test wrapper in
tests/.  We could extend it to ignore such minor differences.

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-06T09:27:33

Ahh... my bad.  I merely rebased the 2nd of those 3 commits.
I should have manually ensured that those files were regenerated.

I'm not used to having generated files under version control.
IMHO, the fact that I ran "make distcheck" (and it did not
regenerate those .[ch] files) means that there is room for
improvement.

What do you think about making "make distcheck" ensure that using
the just-built bison induces no significant change in parse-gram.c?

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-06T08:45:03

Le 6 mai 2012 à 09:31, Jim Meyering a écrit :


FTR, I have installed this.  Your regen step did not
use xmemdup0 for some reason, so the generated code
works, but breaks on the next regeneration.

From e54ec80c0c163e7a9e24fc2eee6c42a61cbe4316 Mon Sep 17 00:00:00 2001
From: Akim Demaille <akim< at >lrde.epita.fr>
Date: Sun, 6 May 2012 10:20:43 +0200
Subject: [PATCH 4/6] maint: import the xmemdup0 gnulib module.

* bootstrap.conf: Require this module.
* src/parse-gram.y: Include xmemdup0.h.
---
 bootstrap.conf   |    3 ++-
 lib/.gitignore   |    2 ++
 src/parse-gram.y |    1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index e1fd548..3303ef3 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
< at >< at > -26,7 +26,8 < at >< at > gnulib_modules='
   quote quotearg realloc-posix
   spawn-pipe stdbool stpcpy strdup-posix strerror strtoul strverscmp
   unistd unistd-safer unlocked-io update-copyright unsetenv verify
-  warnings xalloc xalloc-die xstrndup
+  warnings
+  xalloc xalloc-di

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-06T07:31:16

Precisely.


Hah!  That's even better.
It's not often that one can replace so many lines with just one.

Pushed.

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-06T06:58:00

Hi Jim!

This is perfect, push whenever you want.

Le 5 mai 2012 à 15:26, Jim Meyering a écrit :


For my education, you prefer memdup to strndup because of
of the inner strnlen of the latter, right?  It makes plenty
of sense, but this split memdup + '=0' is not nice looking.
It would be cleaner to have say xmemdup0 which would add
this 0.

Actually, I just grepped xmemdup in gnulib to see if there
are many such memdup + '=0', and here is what I found:

lib/xmemdup0.c:
char *
xmemdup0 (void const *p, size_t s)
{
  char *result = xcharalloc (s + 1);
  memcpy (result, p, s);
  result[s] = 0;
  return result;
}

:)  So please, make it

    {
      char *name = xmemdup0 (name_start, strspn (name_start, alphanum));
      muscle_pair_list_grow (type, decl, name);
      free (name);
    }

(I think this is the last time I will bug you with this patch :)
but looking at the surrounding code, I see that we do not support
\n in %parse-param, which is not nice, I will make another patch
on top of yours).