In article <E1R4kBO-0000j0-19@camel.ams6.corp.booking.com>, sprout@cpan.org (Father Chrysostomos) wrote: > commit 309aab3af38b00c733d3e986808e79b53ffc4bab > Author: Father Chrysostomos <sprout@cpan.org> > Date: Fri Sep 16 18:54:57 2011 -0700 > > Make goto &CORE::sub use the right lexical scope [snip] > ----------------------------------------------------------------------- > [snip] > --- a/t/op/coresubs.t > +++ b/t/op/coresubs.t > @@ -108,6 +108,13 @@ while(<$kh>) { > } > } > > +$tests++; > +# This subroutine is outside the warnings scope: > +sub foo { goto &CORE::abs } > +use warnings; > +$SIG{__WARN__} = sub { like shift, qr\^Use of uninitialized\ }; > +foo(undef); Under -DDEBUGGING, this new test looks like: % ./perl TEST op/coresubs.t t/op/coresubs ... Attempt to free unreferenced scalar: SV 0x1008030b0 during global destruction. ok All tests successful. u=0.01 s=0.00 cu=0.89 cs=0.01 scripts=1 tests=1033 on OS X, and on VMS like: $ mcr []perl TEST [.op]coresubs.t t/[.op]coresubs ... FAILED--unexpected output at test 1030 Failed 1 test out of 0, 0.00% okay. [.op]coresubs.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". u=80.97 s=0.00 cu=0.00 cs=0.00 scripts=0 tests=0 %SYSTEM-F-ABORT, abort Whatever accident of the implementation causes t/TEST to consider a warning to be either something that can be safely ignored while passing it along for the interested reader or "unexpected output" that causes the test to fail, there is definitely something up either with the new test or with what it's testing.