[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Bison 2.5] testsuite: 3 4 7 8 16 21 33 36 45 68 69 70 92 93 94
From: |
Akim Demaille |
Subject: |
Re: [GNU Bison 2.5] testsuite: 3 4 7 8 16 21 33 36 45 68 69 70 92 93 94 95 139 143 145 151 160 220 221 222 228 233 246 failed |
Date: |
Mon, 5 Mar 2012 19:39:42 +0100 |
Le 2 mars 2012 à 13:52, Lie Yan a écrit :
> Lie Yan
Hi!
Thanks for the report. There seem to be several
issues in there:
> 3. input.at:161: testing ...
> ./input.at:162: bison input.y
> ./input.at:162: VALGRIND_OPTS="$VALGRIND_OPTS --leak-check=summary
> --show-reachable=no"; export VALGRIND_OPTS; bison input.y -Werror
> stderr:
> /Users/robin/Downloads/bison-2.5/src/bison: extra operand `-Werror'
> Try `/Users/robin/Downloads/bison-2.5/src/bison --help' for more information.
> /Users/robin/Downloads/bison-2.5/tests/testsuite.dir/at-groups/3/test-source:
> line 215: test: -lt: unary operator expected
> ./input.at:162: sed 's,.*/\(bison: warnings being treated as errors\)$,\1,' \
> stderr 1>&2
> --- experr 2012-03-02 15:42:36.000000000 +0300
> +++ /Users/robin/Downloads/bison-2.5/tests/testsuite.dir/at-groups/3/stderr
> 2012-03-02 15:42:36.000000000 +0300
> @@ -1,2 +1,2 @@
> -bison: warnings being treated as errors
> -input.y:11.10-32: warning: unset value: $$
> +/Users/robin/Downloads/bison-2.5/src/bison: extra operand `-Werror'
> +Try `/Users/robin/Downloads/bison-2.5/src/bison --help' for more information.
> 3. input.at:161: 3. Unused values (input.at:161): FAILED (input.at:162)
One seems to be that getopt does not accept
options after arguments. If you could try
to run
./tests/bison -Werror tests/testsuite.dir/003/input.y
and
./tests/bison tests/testsuite.dir/003/input.y -Werror
I guess the first one works, but not the second. (run
this from the directory into which you compiled bison, the one
from where you ran configure).
I don't know why getopt behaves this way. According to
config.log, getopt on your machine was rejected, and
bison should use it's embedded copy:
> | gl_LIBOBJS=' argmatch.o asnprintf.o basename.o basename-lgpl.o cloexec.o
> dirname.o dirname-lgpl.o dup-safer.o error.o fd-safer.o fopen-safer.o
> fprintf.o getopt.o getopt1.o hash.o ioctl.o isnand.o isnanf.o isnanl.o
> obstack.o open.o pipe-safer.o printf.o printf-args.o printf-parse.o quote.o
> quotearg.o rawmemchr.o snprintf.o sprintf.o stat.o strchrnul.o stripslash.o
> strverscmp.o vasnprintf.o vfprintf.o vsnprintf.o vsprintf.o wcwidth.o
> xmalloc.o'
I see this in your config.log too (the confdefs.h section):
> #define HAVE_GETOPT_H 1
> #define HAVE_GETOPT_H 1
> #define HAVE_GETOPT_LONG_ONLY 1
> #define __GETOPT_PREFIX rpl_
> #define GNULIB_TEST_GETOPT_GNU 1
> #define __GETOPT_PREFIX rpl_
which seems good. So I don't know why it does not
seem to work. It's a pity that getopt.m4 does not
AC_SUBST([REPLACE_GETOPT]), so I can't see the
result in config.log, but it seems quite clear
that it is set to 1.
Hum. The most probable issue is that you have
POSIXLY_CORRECT defined in your environment. The
test suite is robust to this provided that it
is defined to 1:
# POSIXLY_CORRECT=1 causes bison to complain if options are added
# after the grammar file name, so skip these checks in that case.
if test x"$POSIXLY_CORRECT" != x1; then
Indeed, we should not check for =1, but just being
defined. getopt reads:
Using 'getopt' or setting the environment variable POSIXLY_CORRECT
disables permutation.
d->__posixly_correct = posixly_correct || !!getenv ("POSIXLY_CORRECT");
I'll fix the test suite for this issue. Now the second problem
comes from (tests/local.at):
]AT_DATA([[at-bison-check-warnings]], [$4])[
at_bison_check_first="` \
sed -n '/: warning: /=' at-bison-check-warnings \
| sed -n 1p \
`"
at_bison_check_first_tmp="` \
sed -n '/conflicts: [0-9].*reduce$/=' at-bison-check-warnings \
| sed -n 1p \
`"
if test $at_bison_check_first_tmp -lt $at_bison_check_first; then
at_bison_check_first=$at_bison_check_first_tmp
fi
indeed, there is no reason for these variables to
be always defined. I will address this too.
Again, thanks for the report! As you can see, your
Bison seems sane, these are only issues with the
test suite.