Re^3: B::Xref buggy?

[dave_the_m]

Looking at the src code for B::Xref, it appears to scan the op tree in execution (op_next) order, noting the current line and file number any time it sees an OP_NEXTSTATE. When it comes to an op that has more than one possible next op (such as loops etc) it recursively follows each branch, without restoring the old file/line number on each return. Thus giving silly results.

Dave.

[LanX]

Thanks Dave.

I'm no expert on OP-Codes but that doesn't seem to be always the case.

On a simpler example the insides of while are parsed but the following line-number is wrong

(manually added #:markers)

D:\tmp>more tst_b_xref2.pl
use strict;
use warnings;
my $sth;

while ( my @row =$sth->fetchrow) {    #:5 intro
    print "@row";                     #:6 used
}

activating debug options

D:\tmp>perl -MO=Xref,-r,-d,-DO tst_b_xref2.pl
OP (0x163e650) enter
COP (0x10fcdd8) nextstate
OP (0x10fce38) padsv
tst_b_xref2.pl   (main)           3 (lexical)       $ sth             
+ intro
COP (0x163e698) nextstate
LOOP (0x163e740) enterloop
OP (0x16579c8) pushmark
OP (0x1657a50) pushmark
PADOP (0x1657b48) gvsv
tst_b_xref2.pl   (main)           5 main            $ "               
+ used
OP (0x1657ad0) padav
tst_b_xref2.pl   (main)           5 (lexical)       @ row             
+ used  #:used?
LISTOP (0x1657a88) join
LISTOP (0x1657a08) print
OP (0x163e870) unstack
OP (0x1657bd0) pushmark
OP (0x1657d60) pushmark
OP (0x10fcd18) padsv
tst_b_xref2.pl   (main)           5 (lexical)       $ sth             
+ used     
METHOP (0x1657d18) method_named
UNOP (0x1657cd0) entersub
tst_b_xref2.pl   (main)           5 (lexical)       $ sth             
+ subused
OP (0x1657c50) pushmark
OP (0x10fcd58) padav
tst_b_xref2.pl   (main)           5 (lexical)       @ row             
+ intro #:5?intro?
BINOP (0x1657b88) aassign
LOGOP (0x163e7e0) and
BINOP (0x163e6f8) leaveloop
LISTOP (0x10fcd90) leave
tst_b_xref2.pl syntax OK

It's worth noting that B::Concise and B::Deparse are getting the line-numbers right:

D:\tmp>perl -MO=Concise,-src tst_b_xref2.pl
n  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
# 3: my $sth;
2     <;> nextstate(main 3 tst_b_xref2.pl:3) v:*,&,{,x*,x&,x$,$ ->3
3     <0> padsv[$sth:3,9] vM/LVINTRO ->4
# 5: while ( my @row =$sth->fetchrow) {                             #:
+line 5
4     <;> nextstate(main 4 tst_b_xref2.pl:5) v:*,&,{,x*,x&,x$,$ ->5
m     <2> leaveloop vK/2 ->n
5        <{> enterloop(next->c last->m redo->6) v ->d
-        <1> null vK/1 ->m
l           <|> and(other->6) vK/1 ->m
k              <2> aassign[t4] sKS/COM_AGG ->l
-                 <1> ex-list lK ->i
d                    <0> pushmark s ->e
h                    <1> entersub[t3] lKS/TARG,STRICT ->i
e                       <0> pushmark s ->f
f                       <0> padsv[$sth:3,9] sM ->g
g                       <.> method_named[PV "fetchrow"] l ->h
-                 <1> ex-list lK ->k
i                    <0> pushmark s ->j
j                    <0> padav[@row:5,8] lRM*/LVINTRO ->k           #:
+@row intro
-              <@> lineseq vK ->-
-                 <@> scope vK ->c
# 6:     print "@row";                                              #:
+line 6
-                    <;> ex-nextstate(main 7 tst_b_xref2.pl:6) v:*,&,x
+*,x&,x$,$ ->6
b                    <@> print vK ->c
6                       <0> pushmark s ->7
a                       <@> join[t6] sK/2 ->b
7                          <0> pushmark s ->8
-                          <1> ex-rv2sv sK/STRICT,1 ->9
8                             <#> gvsv[*"] s ->9
9                          <0> padav[@row:5,8] l ->a                #:
+@row used
c                 <0> unstack v ->d
tst_b_xref2.pl syntax OK

So probably B::Xref is better implemented by extending B::Concise ?

[dave_the_m]

I'm no expert on OP-Codes but that doesn't seem to be always the case.

Nothing you've shown me contradicts what I think is the problem.

So probably B::Xref is better implemented by extending B::Concise ?

That doesn't really make any sense. Both are implemented on top of of B.pm, which presents an op tree as a a connected collection of perl node objects which can be interrogated by suitable perl code. Concise does minimal work, just dumping the nodes in depth-first or execution order. Xref scans the same structure but does more clever things, which involves trying to keep track of the current line number.

Xref needs fixing by being smarter when scanning sub-nodes associated with nodes which have multiple execution paths.

Dave.

[LanX]

> That doesn't really make any sense.

Let me elaborate:

It's possible to apply a callback to Concise to handle the logic with B::Concise::add_callback

This would make debugging much easier and more intuitive.

I'll try as soon as I have closed other projects in the pipeline.

[ikegami]

It's worth noting that B::Concise and B::Deparse are getting the line-numbers right:

uh, concise doesn't list a line number for the op in question.

[LanX]

sorry?

  v
# 5: while ( my @row =$sth->fetchrow) {                             #:
+line 5
4     <;> nextstate(main 4 tst_b_xref2.pl:5) v:*,&,{,x*,x&,x$,$ ->5
                                          ^