From @andk

git bisect

4d8ac5c is the first bad commit
commit 4d8ac5c
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Thu Dec 8 12​:49​:33 2011 -0800

  Deparse (eof)+1 correctly

diagnostics

http​://www.cpantesters.org/cpan/report/dfcff7bc-2327-11e1-b847-4d82dc02392a

perl -V

Summary of my perl5 (revision 5 version 15 subversion 5) configuration​:
  Commit id​: 4d8ac5c
  Platform​:
  osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux-thread-multi
  uname='linux k83 2.6.32-5-amd64 #1 smp thu nov 3 03​:41​:26 utc 2011 x86_64 gnulinux '
  config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.15.5-331-g4d8ac5c/9980 -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Duseithreads -Uuselongdouble -DDEBUGGING=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.4.5', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib /lib64 /usr/lib64
  libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=/lib/libc-2.11.2.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.11.2'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
  PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT
  PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_DEVEL
  USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO
  USE_PERL_ATOF USE_REENTRANT_API
  Built under linux
  Compiled at Dec 22 2011 23​:29​:32
  @​INC​:
  /home/src/perl/repoperls/installed-perls/perl/v5.15.5-331-g4d8ac5c/9980/lib/site_perl/5.15.5/x86_64-linux-thread-multi
  /home/src/perl/repoperls/installed-perls/perl/v5.15.5-331-g4d8ac5c/9980/lib/site_perl/5.15.5
  /home/src/perl/repoperls/installed-perls/perl/v5.15.5-331-g4d8ac5c/9980/lib/5.15.5/x86_64-linux-thread-multi
  /home/src/perl/repoperls/installed-perls/perl/v5.15.5-331-g4d8ac5c/9980/lib/5.15.5
  .

--
andreas

From @cpansprout

On Thu Dec 22 21​:11​:29 2011, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

git bisect
----------
4d8ac5c is the first bad commit
commit 4d8ac5c
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Thu Dec 8 12​:49​:33 2011 -0800

Deparse \(eof\)\+1 correctly

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/dfcff7bc-2327-11e1-b847-
4d82dc02392a

B​::Deparse currently cannot distinguish between left and right
precedence. If you call length($foo) in additive context, it gets
parentheses, whether they are needed or not. In other words, it does
not distinguish between these two cases, in determining whether
parentheses should be present​:

  $foo = length($bar) + 1;
  $foo = 1 + length $bar;

(The latter gets parentheses in Deparse output.)

The llafr (looks-like-a-function rule) does not apply to return. There
was a bug in B​::Deparse that caused it to render ‘(return)+1’ as
‘return() + 1’, which is wrong, because ‘return() + 1’ means
‘return(()+1)’. So I fixed it by surrounding the ‘return’ with
parentheses at the right precedence level.

So the same inability comes into play in this circumstance​:

  $foo = (return) + 1;
  $foo = 1 + return;

where the second line gets parentheses, too, in Deparse output.

Just thinking about fixing this limitation makes my head hurt. Is this
something you (Paul Johnson) can work around?

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @cpansprout

On Thu Dec 22 23​:08​:27 2011, sprout wrote​:

On Thu Dec 22 21​:11​:29 2011, andreas.koenig.7os6VVqR@​franz.ak.mind.de
wrote​:

git bisect
----------
4d8ac5c is the first bad commit
commit 4d8ac5c
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Thu Dec 8 12​:49​:33 2011 -0800

Deparse \(eof\)\+1 correctly

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/dfcff7bc-2327-11e1-b847-
4d82dc02392a

B​::Deparse currently cannot distinguish between left and right
precedence. If you call length($foo) in additive context, it gets
parentheses, whether they are needed or not. In other words, it does
not distinguish between these two cases, in determining whether
parentheses should be present​:

$foo = length($bar) + 1;
$foo = 1 + length $bar;

(The latter gets parentheses in Deparse output.)

The llafr (looks-like-a-function rule) does not apply to return. There
was a bug in B​::Deparse that caused it to render ‘(return)+1’ as
‘return() + 1’, which is wrong, because ‘return() + 1’ means
‘return(()+1)’. So I fixed it by surrounding the ‘return’ with
parentheses at the right precedence level.

So the same inability comes into play in this circumstance​:

$foo = (return) + 1;
$foo = 1 + return;

And it applies to ||, too, as return has low precedence.

where the second line gets parentheses, too, in Deparse output.

Just thinking about fixing this limitation makes my head hurt. Is this
something you (Paul Johnson) can work around?

--

Father Chrysostomos

From @pjcj

On Thu, Dec 22, 2011 at 11​:09​:07PM -0800, Father Chrysostomos via RT wrote​:

On Thu Dec 22 23​:08​:27 2011, sprout wrote​:

The llafr (looks-like-a-function rule) does not apply to return. There
was a bug in B​::Deparse that caused it to render ‘(return)+1’ as
‘return() + 1’, which is wrong, because ‘return() + 1’ means
‘return(()+1)’. So I fixed it by surrounding the ‘return’ with
parentheses at the right precedence level.

So the same inability comes into play in this circumstance​:

$foo = (return) + 1;
$foo = 1 + return;

And it applies to ||, too, as return has low precedence.

where the second line gets parentheses, too, in Deparse output.

Just thinking about fixing this limitation makes my head hurt. Is this
something you (Paul Johnson) can work around?

If the change is deliberate and working as designed (which seems to be
the case) then it is certainly something that I can work around.

Thanks Andreas for highlighting the problem and bisecting it, and thanks
Father Chrysostomos for fixing the original problem and for the
explanation.

TODO

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

From @cpansprout

Devel​::Cover has 20 modules depending on it directly, and 54 following
the dependents recursively, so I’m adding this ticket to the 5.16
blockers’ list.

From @rjbs

This is not *really* going to block 5.16.0, but I want to keep an eye on this as it approaches.
Paul will be at the QA Hackathon (I think!) which is in two weeks. I will talk to him there or
before that to see what we can expect.

From @rjbs

Fixed by Devel-Cover-0.80

From [Unknown Contact. See original ticket]

Fixed by Devel-Cover-0.80

@rjbs - Status changed from 'open' to 'resolved'