Help needed on a new 5.10 warning

mpeters on 2009-09-15T21:48:20

I'm trying to run an existing application on 5.10 for the first time (5.10.0 for right now) and am getting a warning that is not making it easy for me to track down. Any help from the lazy web would be appreciated.



It goes like this:

  Variable "$x" is not available at (re_eval 1070) line 1.

I'm assuming this is pretty deep inside some dependency I'm using (of which my application probably has an old version which doesn't play nicely with 5.10). Google is no help here as it returns a lot of CPAN testers results with the same warning for various modules (http://www.mail-archive.com/cpan-testers@perl.org/msg652326.html, http://trouchelle.com/perl/ppmrepview.pl?id=33577&v=10).



My normal trick of using

  $SIG{__WARN__} = \*Carp::cluck;

to get a nice stack trace of where the warning is coming from is not actually giving me a stack trace. Anyone have any extra ideas?

---

The code knows

speters on 2009-09-16T13:01:08

The code that throws that warning is in pad.c. Below is the code. I think the comment explains why the warning is being thrown. /* trying to capture from an anon prototype? */ if (CvCOMPILED(cv) ? CvANON(cv) && CvCLONE(cv) && !CvCLONED(cv) : *out_flags & PAD_FAKELEX_ANON) { if (warn && ckWARN(WARN_CLOSURE)) Perl_warner(aTHX_ packWARN(WARN_CLOSURE), "Variable \"%s\" is not available", name); *out_capture = NULL; }

Re:The code knows

mpeters on 2009-09-16T13:52:10

Yeah, I was also able to trace where in the *perl* code the warning was coming from, but I'm trying to figure out which *module* in the huge tree of modules being used is using a construct that is causing the warning to be thrown.

Re: Help needed on a new 5.10 warning

kid51 on 2009-09-17T03:06:05

All I can offer is that during some recent attempts to refactor ExtUtils::ParseXS, I encountered this warning when attempting to make that module work under 'use strict'. IIRC, I got it in a part of the code that was using the "deferred regex evaluation" feature -- ??{ $some_variable } -- inside of itself.

$bal = qr[(?:(?>[^()]+)|\((??{ $bal })\))*]; # ()-balanced

$cast = qr[(?:\(\s*SV\s*\*\s*\)\s*)?]; # Optional (SV*) cast

$size = qr[,\s* (??{ $bal }) ]x; # Third arg (to setpvn)

Again, IIRC, my temporary workaround was to declare $bal as 'our' rather than 'my'. But since my work on this module has stalled, I can't offer any better insight. Note that 'perldoc perldiag' hints at this being a closure-related problem ... but I didn't encounter it in a closure-related situation at all.

Thank you very much.

kid51

Re: Help needed on a new 5.10 warning

mpeters on 2009-09-17T13:03:57

Thanks for the advice. I eventually tracked it down to Regexp::Common and was able to remove the warning if I just imported the number specific regexes:

  use Regexp::Common qw(number);

try Carp::Always module

duncand on 2009-09-17T06:41:01

I've found success with the Carp::Always module. All I have to do is say "use Carp::Always" at the top of my program, and any time an exception is thrown it includes a stack trace, which is great for diagnosing all the exceptions from 'use strict' or 'use warnings fatal'. That said it /may/ not be compatible with other attempts to override the signal handlers. I now make it common practice to put "use Carp::Always" at the top of all my module t/*.t files.

Re:try Carp::Always module

bart on 2009-09-17T17:41:29

I hope using -MCarp::Always on the command line has the same effect as editing use Carp::Always; into the code?

Re:try Carp::Always module

duncand on 2009-09-17T18:17:55

I found that the effects of 'use Carp::Always' are global in scope, so I assume that loading it with -M on the command line will work as well as placement into code.