Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

unexpected OP_PADRANGE during Devel::Cover on v5.18.0-RC1

10 views
Skip to first unread message

David Golden

unread,
May 11, 2013, 9:49:30 PM5/11/13
to p5p, Paul Johnson
I don't have time to fully dig into the cause but I'm getting this
when running tests with Devel::Cover 1.02 on various dists of mine:

unexpected OP_PADRANGE at
/Users/david/perl5/perlbrew/perls/18.0-rc1/lib/5.18.0/B/Deparse.pm
line 1250.

It doesn't happen under regular "make test".

Can anyone else replicate this?

David

--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

James E Keenan

unread,
May 11, 2013, 10:47:22 PM5/11/13
to perl5-...@perl.org, Paul Johnson
On 5/11/13 9:49 PM, David Golden wrote:
> I don't have time to fully dig into the cause but I'm getting this
> when running tests with Devel::Cover 1.02 on various dists of mine:
>
> unexpected OP_PADRANGE at
> /Users/david/perl5/perlbrew/perls/18.0-rc1/lib/5.18.0/B/Deparse.pm
> line 1250.
>
> It doesn't happen under regular "make test".
>
> Can anyone else replicate this?
>

From pod/perldelta.pod:

* A new op type, "OP_PADRANGE" has been introduced. The perl peephole
optimiser will, where possible, substitute a single padrange op for a
pushmark followed by one or more pad ops, and possibly also skipping
list and nextstate ops. In addition, the op can carry out the tasks
associated with the RHS of a "my(...) = @_" assignment, sothose ops may
be optimised away too.

From what (little) I know of Devel::Cover's internals, I'm not
surprised that the introduction of a new op type would pose problems.

Did you encounter any problem in running Devel::Cover's own tests when
you went to install it on 18.0-rc1? Or is this something that only
shows up when you use Devel::Cover while running other tests?

Thank you very much.
Jim Keenan

David Golden

unread,
May 12, 2013, 7:53:50 AM5/12/13
to James E Keenan, p5p, Paul Johnson
On Sat, May 11, 2013 at 10:47 PM, James E Keenan <jk...@verizon.net> wrote:
> Did you encounter any problem in running Devel::Cover's own tests when you
> went to install it on 18.0-rc1? Or is this something that only shows up
> when you use Devel::Cover while running other tests?

It installed as part of my BeLike task, so I didn't see it's test
output. But it didn't fail.

Nicholas Clark

unread,
May 12, 2013, 7:59:42 AM5/12/13
to David Golden, Cc: p5p <perl5-porters@perl.org>, Paul Johnson
On Sun, May 12, 2013 at 07:53:50AM -0400, David Golden wrote:
> On Sat, May 11, 2013 at 10:47 PM, James E Keenan <jk...@verizon.net> wrote:
> > Did you encounter any problem in running Devel::Cover's own tests when you
> > went to install it on 18.0-rc1? Or is this something that only shows up
> > when you use Devel::Cover while running other tests?
>
> It installed as part of my BeLike task, so I didn't see it's test
> output. But it didn't fail.

Which, sadly, suggests that something needs more tests :-/

(But, thinking about it, that "something" might be B::Deparse.
Fortunately B::Deparse is dual life so it can be field upgraded)

Nicholas Clark

James E Keenan

unread,
May 12, 2013, 8:13:50 AM5/12/13
to perl5-...@perl.org
On 5/12/13 7:59 AM, Nicholas Clark wrote:

>
> Which, sadly, suggests that something needs more tests :-/
>
> (But, thinking about it, that "something" might be B::Deparse.
> Fortunately B::Deparse is dual life so it can be field upgraded)
>

Probably so. I don't think anyone made any changes to Devel::Cover in
anticipation Perl 5.18.0, whereas the warning was thrown from B::Deparse.

Dave Mitchell

unread,
May 13, 2013, 11:02:38 AM5/13/13
to David Golden, p5p, Paul Johnson
On Sat, May 11, 2013 at 09:49:30PM -0400, David Golden wrote:
> I don't have time to fully dig into the cause but I'm getting this
> when running tests with Devel::Cover 1.02 on various dists of mine:
>
> unexpected OP_PADRANGE at
> /Users/david/perl5/perlbrew/perls/18.0-rc1/lib/5.18.0/B/Deparse.pm
> line 1250.
>
> It doesn't happen under regular "make test".
>
> Can anyone else replicate this?

Can you quote an example of a publicly available module or file where it
fails for you?

The way Deparse was modified to handle the new PADRANGE op was that I
added a new overlay facility to B that allows you to see a modified view of
the op tree; then Deparse uses this feature to 'undo' the PADRANGE
optimisation. Thus in theory Deparse should never encounter a PADRANGE op
(yet clearly it is for some reason).

--
Thank God I'm an atheist.....

Dave Mitchell

unread,
May 13, 2013, 11:36:36 AM5/13/13
to Paul Johnson, David Golden, p5p
On Mon, May 13, 2013 at 05:18:20PM +0200, Paul Johnson wrote:
> Oops, I hadn't noticed this problem either.
>
> Devel::Cover does nasty things with B::Deparse, so it's quite possible
> that it's skipping the overlay you have added. But yes, a failing
> example would be nice.

If its any help, the relevant blead commits are:

commit 71324a3bc4a9e86bdeeabcaf87f9cdac28ba7510
Author: David Mitchell <da...@iabyn.com>
AuthorDate: Tue Oct 23 21:39:10 2012 +0100
Commit: David Mitchell <da...@iabyn.com>
CommitDate: Sat Nov 10 13:39:30 2012 +0000

add $B::overlay feature

This allows you to alter the read-only "view" of an optree, by making
particular B::*OP methods on particular op nodes return customised values.
Intended to be used by B::Deparse to "undo" optimisations, thus making it
easier to add new optree optimisations without breaking Deparse.


and the Deparse.pm part of:

commit a7fd8ef68b459a13ba95615ec125e2e7ba656b47
Author: David Mitchell <da...@iabyn.com>
AuthorDate: Mon Sep 24 13:50:22 2012 +0100
Commit: David Mitchell <da...@iabyn.com>
CommitDate: Sat Nov 10 13:39:31 2012 +0000

add padrange op


--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"

David Golden

unread,
May 13, 2013, 1:44:05 PM5/13/13
to Dave Mitchell, p5p, Paul Johnson
On Mon, May 13, 2013 at 11:02 AM, Dave Mitchell <da...@iabyn.com> wrote:
> Can you quote an example of a publicly available module or file where it
> fails for you?

I hit it developing CPAN::Common::Index (only on my github) and
confirmed it with Path::Tiny.

I tested Path::Tiny both under "dzil cover" and then also just build
up a distribution directory as if I were about to ship ("dzil build")
and then confirmed it manually with "cover -test" there.

Paul Johnson

unread,
May 13, 2013, 11:18:20 AM5/13/13
to Dave Mitchell, David Golden, p5p
On Mon, May 13, 2013 at 04:02:38PM +0100, Dave Mitchell wrote:
Oops, I hadn't noticed this problem either.

Devel::Cover does nasty things with B::Deparse, so it's quite possible
that it's skipping the overlay you have added. But yes, a failing
example would be nice.

Unless we do trace this back to B::Deparse, Devel:Cover failing, whilst
unfortunate, is not a reason to hold up 5.18.

I'll also try to look into this asap.

--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net

Paul Johnson

unread,
May 20, 2013, 2:38:17 PM5/20/13
to Dave Mitchell, David Golden, p5p
Thanks for those pointers. I have just released version 1.03 of
Devel::Cover which fixes this particular problem.

The warning wasn't causing any functional problems with Devel::Cover,
and wasn't a problem with the perl core in any way. (Expect that
B::Deparse is too monolithic.)
0 new messages