The issue is that when PL_perldb is true pad_tidy() makes every compiled
sub close over all visible variables in order to support eval() being
performed in that lexical scope. Normally this total closure only happens
for subs that contain an eval() expression in scope, but when debugging
an eval can happen via the debugger without being compiled in scope.
The desired state of affairs is that lift() will not fail merely due
to the possibility of debugger-induced eval(), but will still croak
if the expression closes over outer variables for any other reason.
If anyone does attempt an eval from the debugger during execution of a
lifted expression then any outcome is acceptable.
Possible approach: checking CvCLONE(PL_compcv) *before* calling
newATTRSUB() determines whether it has any real lexical variable
references. Checking PL_cv_has_eval (which pad_tidy() looks at in the
non-debugging case) could determine whether there's a real eval().
Then ignore the fact that the CLONE flag got set by newATTRSUB().
However, if there are nested lift() operations (which should work),
setting up the total closure for the inner lifted expression will also
set up the same for the outer expression, before the outer expression
has been fully compiled (and so before the earlier CvCLONE check for
the outer expression).
Another approach is to locally turn off PL_perldb. Need to look at what
else that would affect. Could be significant if the lifted expression
includes a (non-closure) sub{} expression, as it would turn off debugging
for the code in that sub which is not being lifted to compile time.
Maybe want to turn PL_perldb back on for such nested subs, but the total
closure effect propagating up the lexical chain would then break the
actual lifted expression again.
-zefram
RT for rt.cpan.org