From c387a7d007c6548d2e60763d8c2db5b64f0746fb Mon Sep 17 00:00:00 2001 From: Father Chrysostomos Date: Sat, 9 Nov 2013 13:22:43 -0800 Subject: [PATCH] perldiag: Two minor tweaks One typo and one copy-and-paste error. --- pod/perldiag.pod | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/pod/perldiag.pod b/pod/perldiag.pod index cbef6d4..98eefee 100644 --- a/pod/perldiag.pod +++ b/pod/perldiag.pod @@ -4938,21 +4938,21 @@ C may break this. (W closure) During compilation, an inner named subroutine or eval is attempting to capture an outer lexical subroutine that is not currently available. This can happen for one of two reasons. First, the lexical -subroutine may be declared in an outer anonymous subroutine that has not -yet been created. (Remember that named subs are created at compile time, -while anonymous subs are created at run-time.) For example, +subroutine may be declared in an outer anonymous subroutine that has +not yet been created. (Remember that named subs are created at compile +time, while anonymous subs are created at run-time.) For example, sub { my sub a {...} sub f { \&a } } -At the time that f is created, it can't capture the current the "a" sub, +At the time that f is created, it can't capture the current "a" sub, since the anonymous subroutine hasn't been created yet. Conversely, the following won't give a warning since the anonymous subroutine has by now been created and is live: sub { my sub a {...} eval 'sub f { \&a }' }->(); -The second situation is caused by an eval accessing a variable that has -gone out of scope, for example, +The second situation is caused by an eval accessing a lexical subroutine +that has gone out of scope, for example, sub f { my sub a {...} -- 2.7.4