Closed p5pRT closed 4 years ago
Please see http://matrix.cpantesters.org/?dist=Devel-Cover .
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
The RT System itself - Status changed from 'new' to 'open'
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
@pjcj I assume we can close this?
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.
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.
This seems to have been reported here. Cross linking. https://github.com/pjcj/Devel--Cover/issues/260
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
@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).
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.
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. :)
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.
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.
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 :)
Thank you @pjcj!
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!
Migrated from rt.perl.org#134475 (status was 'open')
Searchable as RT134475$