summaryrefslogtreecommitdiff
path: root/pp_ctl.c
diff options
context:
space:
mode:
authorDavid Mitchell <davem@iabyn.com>2013-08-06 16:34:50 +0100
committerDavid Mitchell <davem@iabyn.com>2013-08-06 16:44:12 +0100
commitc3923c33af542d8764d5a1e4eb5d7b311f443b89 (patch)
treec39cf200d52272b7cde8931a59fed40bc1fd4c7f /pp_ctl.c
parent11609d9c96f9c025675f6215051ab94d6735ddd9 (diff)
downloadperl-c3923c33af542d8764d5a1e4eb5d7b311f443b89.tar.gz
reparse compile-time /(?{})/ in right scope
When a compile-time regex like /...(?{ code-block }) .../ is compiled in the presence of constant and concat overloading, this can cause (still at compile-time) for the pattern to be evaled and re-compiled, in order to re-compile any code-blocks that got messed up during the overloading and thus whose text no longer matches that which the perl parser previously compiled. When this happens, eval_sv() happens to be called when the perl parser is still in compiling state; normally its called from running state. This tickles an undiscovered bug in Perl_find_runcv_where(), which finds the current cop sequence by looking at PL_curcop->cop_seq. At compile time, we need to get it from PL_cop_seqmax instead.
Diffstat (limited to 'pp_ctl.c')
-rw-r--r--pp_ctl.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/pp_ctl.c b/pp_ctl.c
index ff3d661a70..1f9432b9f6 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -3274,7 +3274,11 @@ Perl_find_runcv_where(pTHX_ U8 cond, IV arg, U32 *db_seqp)
int level = 0;
if (db_seqp)
- *db_seqp = PL_curcop->cop_seq;
+ *db_seqp =
+ PL_curcop == &PL_compiling
+ ? PL_cop_seqmax
+ : PL_curcop->cop_seq;
+
for (si = PL_curstackinfo; si; si = si->si_prev) {
I32 ix;
for (ix = si->si_cxix; ix >= 0; ix--) {