Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.91k stars 542 forks source link

BBC: Blead Breaks Devel::Cover #17170

Closed p5pRT closed 4 years ago

p5pRT commented 4 years ago

Migrated from rt.perl.org#134475 (status was 'open')

Searchable as RT134475$

p5pRT commented 4 years ago

From carlos@carlosguevara.com

Please see http​://matrix.cpantesters.org/?dist=Devel-Cover .

Perl Info ``` Flags: category=core severity=low Site configuration information for perl 5.31.5: Configured by cpan at Thu Oct 3 01:17:22 CDT 2019. Summary of my perl5 (revision 5 version 31 subversion 5) configuration: Commit id: d870e48d0f79756c36f71c7a21e6b4e8edf017c0 Platform: osname=linux osvers=5.2.17-200.fc30.x86_64 archname=x86_64-linux-thread-multi uname='linux cjg-fedora30 5.2.17-200.fc30.x86_64 #1 smp mon sep 23 13:42:32 utc 2019 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Dprefix=~/bin/perl-blead -Dscriptdir=~/bin/perl-blead/bin -Dusedevel -Duse64bitall -Duseithreads' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2' cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='9.2.1 20190827 (Red Hat 9.2.1-1)' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 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-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lpthread -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc libc=libc-2.29.so so=so useshrplib=false libperl=libperl.a gnulibc_version='2.29' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E' cccdlflags='-fPIC' lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong' @INC for perl 5.31.5: /home/cpan/bin/perl-blead/lib/site_perl/5.31.5/x86_64-linux-thread-multi /home/cpan/bin/perl-blead/lib/site_perl/5.31.5 /home/cpan/bin/perl-blead/lib/5.31.5/x86_64-linux-thread-multi /home/cpan/bin/perl-blead/lib/5.31.5 Environment for perl 5.31.5: HOME=/home/cpan LANG=en_US.UTF-8 LANGUAGE (unset) LC_ALL=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/cpan/bin/perl-blead/bin:/home/cpan/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 4 years ago

From @jkeenan

On Fri\, 04 Oct 2019 02​:55​:23 GMT\, carlos@​carlosguevara.com wrote​:

This is a bug report for perl from "Carlos Guevara" \carlos@​carlosguevara\.com\, generated with the help of perlbug 1.41 running under perl 5.31.5.

----------------------------------------------------------------- [Please describe your issue here]

Please see http​://matrix.cpantesters.org/?dist=Devel-Cover .

Bisection points to ...

##### 4df857782a14d0973f58f6a629019d29259b2aad is the first bad commit commit 4df857782a14d0973f58f6a629019d29259b2aad Author​: David Mitchell \davem@​iabyn\.com Date​: Fri Sep 20 14​:43​:01 2019 +0100

  put signature ops in their own subtree.  
  The following code​:  
  sub f ($x\,$y) {   study;   }  
  used to compile as​:  
  a \<1> leavesub[1 ref] K/REFC\,1 ->(end)   - \<@​> lineseq KP ->a   1 \<;> nextstate(main 5 p​:5) v​:%\,fea=7 ->2   2 \<+> argcheck(2\,0) v ->3   3 \<;> nextstate(main 3 p​:5) v​:%\,fea=7 ->4   4 \<+> argelem(0)[$x​:3\,5] v/SV ->5   5 \<;> nextstate(main 4 p​:5) v​:%\,fea=7 ->6   6 \<+> argelem(1)[$y​:4\,5] v/SV ->7   - \<;> ex-nextstate(main 5 p​:5) v​:%\,fea=7 ->7   7 \<;> nextstate(main 5 p​:6) v​:%\,fea=7 ->8   9 \<1> study sK/1 ->a   - \<1> ex-rv2sv sK/1 ->9   8 \<$> gvsv(*_) s ->9  
  Following this commit\, it compiles as​:  
  a \<1> leavesub[1 ref] K/REFC\,1 ->(end)   - \<@​> lineseq KP ->a   - \<1> ex-argcheck vK/1 ->7   - \<@​> lineseq vK ->-   1 \<;> nextstate(main 5 p​:5) v​:%\,fea=7 ->2   2 \<+> argcheck(2\,0) v ->3   3 \<;> nextstate(main 3 p​:5) v​:%\,fea=7 ->4   4 \<+> argelem(0)[$x​:3\,5] v/SV ->5   5 \<;> nextstate(main 4 p​:5) v​:%\,fea=7 ->6   6 \<+> argelem(1)[$y​:4\,5] v/SV ->7   - \<;> ex-nextstate(main 5 p​:5) v​:%\,fea=7 ->-   7 \<;> nextstate(main 5 p​:6) v​:%\,fea=7 ->8   9 \<1> study sK/1 ->a   - \<1> ex-rv2sv sK/1 ->9   8 \<#> gvsv[*_] s ->9  
  All the ops associated with the signature have been put in their own   subtree\, with an extra NULL ex-argcheck op "on top". The op on top   serves two purposes​: first\, it makes it easier for Deparse.pm etc to   spot siganure code; secondly\, it may at some point in the future be   upgraded to OP_SIGNATURE when signatures get optimised. It's of type   ex-argcheck only because when being created it needs to be an op type   that's in class UNOP_AUX so that the created op will be suitable for   later optimising\, and making it an ex-type associated with signatures   helps flag it as such.  
  There should be no functional changes apart from the shape of the   optree.

:040000 040000 77c324a1f6affe0f6375ca990e1aadfd6f34669e 3a16c991bed593a71181d30b0758761f85eee75d M ext :040000 040000 54a90cc8a1ca3dff1baac8f31af3d2bd3681d472 89fde9daf957ff5ed8c317c8f8258a5846401502 M lib :100644 100644 dde06e37664a494c155402e3b244f9d3249cade5 1237b50bd7b9654bc236e698960bc53d3580d07f M perly.act :100644 100644 f15762cbb4853c66a891ca2a4b885a2bed6bf65c fd9a19b26149db0cab62670106e4c0eb02a1b283 M perly.h :100644 100644 96709112a205775ad2c2e5aa36d9bbdd6c6dc3d7 0026ead20f49e3eb5e549661aba8c3d4effb60c7 M perly.tab :100644 100644 b49b7c6903e5920f3717a697c7ed59b10674086d 0325d663c065b2a070df3c85ed15c19fc02ea2a2 M perly.y bisect run success That took 1219 seconds. #####

Dave\, can you take a look?

Thank you very much. Jim Keenan

p5pRT commented 4 years ago

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

p5pRT commented 4 years ago

From @pjcj

On Fri\, Oct 04\, 2019 at 05​:44​:23AM -0700\, James E Keenan via RT wrote​:

On Fri\, 04 Oct 2019 02​:55​:23 GMT\, carlos@​carlosguevara.com wrote​:

Dave\, can you take a look?

A very reasonable response from Dave might be that if Devel​::Cover is going to grovel around in the optree then it's going to have to deal with the consequences.

Thanks Carlos for testing and reporting and thanks Jim for the diagnosis.

-- Paul Johnson - paul@​pjcj.net

toddr commented 4 years ago

@pjcj I assume we can close this?

pjcj commented 4 years ago

Well, Devel::Cover hasn't been fixed (I hope to find time to do so before 5.32) but that's hardly the core's problem. So I suppose it depends on whether or not you'd like to track the problem.

toddr commented 4 years ago

I assume that D::C needs fixing most perl versions. You always do a great job following up on that after we do a maint release. So I'm not sure why we'd track that.

toddr commented 4 years ago

This seems to have been reported here. Cross linking. https://github.com/pjcj/Devel--Cover/issues/260

jkeenan commented 4 years ago

I assume that D::C needs fixing most perl versions. You always do a great job following up on that after we do a maint release. So I'm not sure why we'd track that.

Since a change in the core during the current development cycle is the cause of the breakage, we should keep this ticket open as a BBC and have it as a blocker, if only to remind us to check back with @pjcj before release. It's not currently closable.

Thank you very much. Jim Keenan

xsawyerx commented 4 years ago

@pjcj Without pushing you at all, what is the status of it or when do you think you'll have time to approach this? Devel::Cover is pretty high on the list of things we cannot afford to break, even if the author takes responsibility. We will need to revert our changes unless it is fixed by release time (or fairly soon thereafter).

pjcj commented 4 years ago

Thanks for the reminder. Yes, I somehow need to just find some time to look at it. I think I still have a couple of weeks, right? :)

Please don't revert the changes. Dave's work in this area is really important. In fact, if I could pick one area of perl to be further improved it would be the signature work so I certainly don't want to be the cause of slowdowns here.

xsawyerx commented 4 years ago

Thanks for the reminder. Yes, I somehow need to just find some time to look at it. I think I still have a couple of weeks, right? :)

Please don't revert the changes. Dave's work in this area is really important. In fact, if I could pick one area of perl to be further improved it would be the signature work so I certainly don't want to be the cause of slowdowns here.

Thank you for supporting this change.

You have a bit of time and I imagine you have other priorities as well. If there's any way we can help you with this, please let us know. I'll send balloons and alcogel to your house if it helps speed things up. :)

xsawyerx commented 4 years ago

Considering the extra month giving the author more time - and the author requesting to not wait for them - I'm inclined to make this a non-blocker as well. This is with the high hopes that a new version of Devel::Cover would come out in the next month.

toddr commented 4 years ago

I suggest closing this case. I get that Devel::Cover is a crucial module but Paul does a great job keeping up with production releases.

pjcj commented 4 years ago

Just for information Devel::Cover 1.34, released a few minutes ago, should work with 5.32 as well as it does with 5.30. Phew, I think I made it :)

toddr commented 4 years ago

Thank you @pjcj!

jkeenan commented 4 years ago

On 5/16/20 4:06 PM, Paul Johnson wrote:

Just for information Devel::Cover 1.34, released a few minutes ago, should work with 5.32 as well as it does with 5.30. Phew, I think I made it :)

Tests and installs correctly for me on Linux, FreeBSD, OpenBSD and NetBSD. Thanks, Paul!