Spurious "Changing use VERSION" warning for string eval in module #22121
Comments
|
At a first guess without diving into code, I suspect this is caused by whatever code sets up the context of a string eval not doing the right setup with |
|
Random other thought: if this needs fixes to the way that |
|
I think it's a compile-time vs runtime issue. I think this is the steps we go through:
So we don't need the compile-time I expect we need to save PL_prevailing_version for use by pp_entereval, just as we do for hints and restore it as we do for hints before compiling the code in S_doeval_compile(). Unfortunately there's no room in the op, one option is to add it to
s///ee seems to use entereval to do the work: |
|
Here at PTS2024 I've been looking into solving this one. Initially, storing it in the hints hash seems the most attractive as it's conceptually short and relatively light in terms of collateral change, this close to release. The concept seems simple enough - store a Except, most string eval ops don't actually store a hints hash. One is only put there if perl thinks it needs it. If we add this it basically becomes almost uncondition - it would be stored almost all the times. An initial attempt at the fix is #22175 I begin to wonder on the relative tradeoffs between doing it this way, vs. using doing OP_ENTERVAL as an UNOP_AUX - and making such a change this late in the code cycle. Perhaps one to discuss out loud tomorrow... |
A different option might be to define another flag like Unfortunately I won't have time to try it until Monday (UTC+1000). |
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a chnage now, so this is a less intrusive but hackier change to achieve the same aim. See also Perl#22121
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a change now, so this is a less intrusive but hackier change to achieve the same aim. See also Perl#22121
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a change now, so this is a less intrusive but hackier change to achieve the same aim. See also Perl#22121
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a change now, so this is a less intrusive but hackier change to achieve the same aim. See also Perl#22121
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a change now, so this is a less intrusive but hackier change to achieve the same aim. See also Perl#22121
…al op We need to save the value of PL_prevailing_version at the time the eval op was compiled, so it can be put in place during the running code. Ideally we'd do something more robust, like change the OP_ENTERVAL op class into UNOP_AUX, so that the aux vector can store additional information like the version number and perhaps the frozen hints hash. In practice it is far too close to the 5.40 release to contemplate such a change now, so this is a less intrusive but hackier change to achieve the same aim. See also #22121
|
Fixed by #22175 |
Description
The
Changing use VERSION while another use VERSION is in scope is deprecated, and will become fatal in Perl 5.46warning triggers in cases that don't make sense. It looks like theuse VERSIONcontext sometimes leaks intoused modules that use stringeval.This affects CPAN modules like Data::Munge: https://rt.cpan.org/Ticket/Display.html?id=152677
Steps to Reproduce
Contents of
Foo.pm:This runs normally; no warnings:
This triggers a warning, but only for the eval'd code; the main module code is fine, apparently, even though both try to
use v5.14:Expected behavior
No warnings.
Perl configuration
The text was updated successfully, but these errors were encountered: