summaryrefslogtreecommitdiff
path: root/cpan/Module-Build/lib/Module/Build/Notes.pm
diff options
context:
space:
mode:
authorFather Chrysostomos <sprout@cpan.org>2012-08-08 10:00:52 -0700
committerFather Chrysostomos <sprout@cpan.org>2012-08-08 12:24:53 -0700
commit7ef3083086f16586f909089ba7d9cc1468ffe2c5 (patch)
treee33f1b4907e8fedcd0b6995d1e3eb4231f95df67 /cpan/Module-Build/lib/Module/Build/Notes.pm
parent710ba57483decc7a3b32692be6933c6ba9518234 (diff)
downloadperl-7ef3083086f16586f909089ba7d9cc1468ffe2c5.tar.gz
[perl #114018] Let eval close over stale vars in active sub
See also commit cae5dbbe30. These two lines should never produce different values: print $x, "\n"; print eval '$x', "\n"; But they were producing different values if $x happened to have the tale flag set. Even if my in false conditional is not supported (this was the cause of the bug report), it should still work; and it is not the only way to get a stale lexical in an active sub (just the easiest way). As long as the sub containing the eval is active, the eval should be able to see the same variables, stale or not. However, this does get a bit tricky in cases like this, which legiti- mately warn (from t/lib/warnings/pad): { my $x = 1; $y = \$x; # force abandonment rather than clear-in-place at scope exit sub f2 { eval '$x' } } f2(); In this case the f2 sub does not explicitly close over the $x, so by the time the eval is reached the ‘right’ $x is gone. It is only in those cases where the sub containing the eval has the stale variable in its own pad that we can safely ignore the stale flag.
Diffstat (limited to 'cpan/Module-Build/lib/Module/Build/Notes.pm')
0 files changed, 0 insertions, 0 deletions