Spurious "Changing use VERSION" warning for string eval in module

[mauke]

Description The Changing use VERSION while another use VERSION is in scope is deprecated, and will become fatal in Perl 5.46 warning triggers in cases that don't make sense. It looks like the use VERSION context sometimes leaks into used modules that use string eval.

This affects CPAN modules like Data::Munge: https://rt.cpan.org/Ticket/Display.html?id=152677

Steps to Reproduce Contents of Foo.pm:

package Foo;
use v5.14;
eval 'use v5.14';
1

This runs normally; no warnings:

$ ./perl -I. -e 'use Foo;'
$

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:

$ ./perl -I. -e 'use v5.20; use Foo;'
Changing use VERSION while another use VERSION is in scope is deprecated, and will become fatal in Perl 5.46 at (eval 1) line 1.

Expected behavior No warnings.

Perl configuration

Summary of my perl5 (revision 5 version 39 subversion 10) configuration:
  Commit id: 53a6f7aabfcbe508ff3e0835802d2dd2be935816
  Platform:
    osname=linux
    osvers=6.5.0-10027-tuxedo
    archname=x86_64-linux
    uname='linux luum 6.5.0-10027-tuxedo #31 smp preempt_dynamic tue mar 5 10:45:49 utc 2024 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Dcc=cgcc -Dusedevel'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='cgcc'
    ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='-O2'
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='11.4.0'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cgcc'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/x86_64-linux-gnu /usr/lib /usr/lib64
    libs=-lpthread -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=/lib/x86_64-linux-gnu/libc.so.6
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.35'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_LONG_DOUBLE
    HAS_STRTOLD
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_USE_SBOX32
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_DEVEL
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under linux
  Compiled at Apr  4 2024 13:00:21
  %ENV:
    PERLBREW_BASHRC_VERSION="0.74"
    PERLBREW_HOME="/home/mauke/.perlbrew"
    PERLBREW_MANPATH="/home/mauke/perl5/perlbrew/perls/perl-5.38.2/man"
    PERLBREW_PATH="/home/mauke/perl5/perlbrew/bin:/home/mauke/perl5/perlbrew/perls/perl-5.38.2/bin"
    PERLBREW_PERL="perl-5.38.2"
    PERLBREW_ROOT="/home/mauke/perl5/perlbrew"
    PERLBREW_VERSION="0.94"
    PERLDOC="-oman"
    PERL_UNICODE="SAL"
  @INC:
    lib
    /usr/local/lib/perl5/site_perl/5.39.10/x86_64-linux
    /usr/local/lib/perl5/site_perl/5.39.10
    /usr/local/lib/perl5/5.39.10/x86_64-linux
    /usr/local/lib/perl5/5.39.10

[leonerd]

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 PL_prevailing_version

[leonerd]

Random other thought: if this needs fixes to the way that eval ops work, we'll probably need to do the same thing for s///ee substitutions as well.

[tonycoz]

I think it's a compile-time vs runtime issue.

I think this is the steps we go through:

1. use v5.20 is compiled, setting PL_prevailing version to 0x514
2. use Foo requires Foo, which saves hints (and hence PL_prevailing_version) around compilation of Foo.pm
3. during compilation the use v5.14 sets PL_prevailing_version to 0x50e
4. compilation ends and hints are restored, as is PL_prevailing_version, setting it to 0x514
5. execution of the Foo.pm code starts,
6. entereval starts and compiles the string containing use v5.14, but since PL_prevailing_version is still 0x514 we get the warning

So we don't need the compile-time use v5.14 in Foo.pm to reproduce this, and commenting that out does continue to produce the problem:

tony@venus:.../git/perl6$ cat ../M22121.pm
package M22121;
#use v5.14;
eval 'use v5.14';
1
tony@venus:.../git/perl6$ ./perl -I.. -e 'use v5.20; use M22121'
Changing use VERSION while another use VERSION is in scope is deprecated, and will become fatal in Perl 5.46 at (eval 1) line 1.

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 %^H as I used to do for features, though it might be better to make entereval a UNOP_AUX now.

Random other thought: if this needs fixes to the way that eval ops work, we'll probably need to do the same thing for s///ee substitutions as well.

s///ee seems to use entereval to do the work:

$ perl -MO=Concise -e 's/(.*)/$1/ee'
7  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter v ->2
2     <;> nextstate(main 1 -e:1) v:{ ->3
3     </> subst(/"(.*)"/ replstart->4) v ->7
6        <|> substcont(other->3) sK/1 ->(end)
5           <1> entereval[t256] sK/1 ->6
-              <1> null sK*/1 ->5
-                 <@> scope sK ->-
-                    <;> ex-nextstate(main 2 -e:1) v ->4
-                    <1> ex-rv2sv sK/1 ->-
4                       <#> gvsv[*1] s ->5
-e syntax OK

[leonerd]

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 CORE/prevailing_version key into the frozen hinthash copy at compiletime of a string-eval, then retrieve that out at runtime. Since the hash during runtime is itself a copy of the frozen one that is stored in the op, we can delete it out of the running one, so user code would never actually see it.

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 https://github.com/Perl/perl5/pull/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...

[tonycoz]

though it might be better to make entereval a UNOP_AUX now.

A different option might be to define another flag like OPpEVAL_HAS_HH that makes OP_ENTEREVAL expect an integer on the stack, just as HAS_HH makes entereval expect a hash on the stack, and that integer could be used to populate PL_prevailing_version.

Unfortunately I won't have time to try it until Monday (UTC+1000).

[leonerd]

Fixed by #22175