re_eval: clear lexicals in the right pad

(?{...}) deliberately doesn't introduce a new scope (so that the affects of
local() can accumulate across multiple calls to the code). This also means
that the SAVEt_CLEARSVs pushed onto the save stack by lexical declarations
(i.e. (?{ my $x; ... }) also accumulate, and are only processed en-mass at
the end, on exit from the regex. Currently they are usually processed in
the wrong pad (the caller of the pattern, rather than the pads of the
individual code block(s)), leading to random misbehaviour and SEGVs.

Hence the long-standing advice to avoid lexical declarations within
re_evals.

We fix this by wrapping a pair of SAVECOMPPADs around each call to a code
block. Eventually the save stack will be a long accumulation of
SAVEt_CLEARSV's interspersed with SAVEt_COMPPAD's, that when popped
en-mass should unwind in the right order with the right pad at the right
time.

The price to pay for this is two extra additions to the save stack (which
accumulate) for each code call.

A few TODO tests in reg_eval_scope.t now pass, so I'm probably doing the
right thing ;-)

0 files changed, 0 insertions, 0 deletions