commit
3c78429c102e0fe2ad30c60dfe52636b6071ef19 reduced the depth
of recursion in rpeep(), by deferring recursion into branches until a bit
later (so that the recursive call to rpeep was then likely to be shallow).
However, it went one step further: when the chain of op_next's had been
exhausted in the main loop, it processed any remaining deferrred branches
in the main loop rather than recursing. All nice and efficient, but it
broke the expectation that someone who had hooked into rpeep could follow
the chain of op_nexts in each call and visit *all* ops.
This commit removes that optimisation and restores the rpeep hook
expectancy. This shouldn't have any major effect on the depth of
recursion, and its minor inefficiency doesn't really matter for a
one-time compilation-time pass.
# A deep-enough nesting of conditionals defeats the deferring mechanism
# and triggers recursion. Note that this test is sensitive to the details
# rpeep: the main thing it is testing is that rpeep is called more than
-# peep; the details are less important.
+# peep, and that all branches are covered; the order of branch calling is
+# less important.
my $code = q[my ($a,$b); $a =];
$code .= qq{ \$b ? "foo$_" :} for (1..10);
XS::APItest::peep_disable;
is_deeply($record, [ "foo11" ]);
-is_deeply($rrecord, [ qw(foo1 foo2 foo3 foo4 foo5 foo6 foo11) ]);
+is_deeply($rrecord, [
+ qw(foo1 foo2 foo3 foo4 foo5 foo6 foo10 foo9 foo8 foo7 foo11) ]);
while (!o) {
if (defer_ix < 0)
break;
- o = defer_queue[(defer_base + defer_ix--) % MAX_DEFERRED];
- oldop = NULL;
+ CALL_RPEEP(defer_queue[(defer_base + defer_ix--) % MAX_DEFERRED]);
}
if (!o)
break;