Bug #95311 for YATT: Test suite fails with perl 5.19.x

Sat May 03 04:59:51 2014 SREZIC [...] cpan.org - Ticket created

Subject:

Test suite fails with perl 5.19.x

YATT's test suite fails with newest perls (5.19.10, 5.19.11). Following the beginning of the test log run: Output from './Build test': web/cgi-bin/yatt.lib/t/rlimit.t ........... skipped: BSD::Resource is not installed web/cgi-bin/yatt.lib/t/topcgi-redirect.t .. skipped: yatt.cgi and testapp is not installed. # Failed test 'require YATT::Translator::Perl;' # at web/cgi-bin/yatt.lib/t/use.t line 64. # Tried to require 'YATT::Translator::Perl'. # Error: No such class t_attr at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1396, near "my t_attr" # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1396. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. # No such class t_attr at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1402, near "(my t_attr" # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1402. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1407. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1412. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1412. # Global symbol "$var" requires explicit package name at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1413. # No such class t_attr at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1417, near "my t_attr" # /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm has too many errors. # Compilation failed in require at (eval 58) line 2. # Failed test 'require YATT::Translator::Perl::macro_dbfetch;' # at web/cgi-bin/yatt.lib/t/use.t line 64. # Tried to require 'YATT::Translator::Perl::macro_dbfetch'. # Error: Attempt to reload YATT/Translator/Perl.pm aborted. # Compilation failed in require at /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl/macro_dbfetch.pm line 4. # Compilation failed in require at (eval 75) line 2. # Looks like you failed 2 tests of 112. web/cgi-bin/yatt.lib/t/use.t .............. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/112 subtests (less 6 skipped subtests: 104 okay) ... Regards, Slaven

Sat May 03 17:43:33 2014 ANDK [...] cpan.org - Correspondence added

Git bisect brings us to v5.19.2-138-g137da2b already treated in https://rt.perl.org/rt3/Ticket/Display.html?id=119047

Sat May 03 17:43:33 2014 The RT System itself - Status changed from 'new' to 'open'

Mon May 05 06:24:29 2014 hkoba [...] cpan.org - Correspondence added

Thank you for telling me about this failure. Could you/someone explain me about changes about constant sub handling introduced between 5.19.2 and 5.19.3? I noticed attached test do not work after 5.19.3. Is this intentional change? In YATT and other project, I've been used compile time checking with my Dog $spot = ... feature in conjunction with constant sub (in this case 'Dog'), which is generated compile time. To generate constant sub ('Dog' => 'My::Lib::Dog'), I've been used my $sym = do {no strict 'refs'; \*$string}; *$sym = sub () {$value}; Is this obsoleted anymore? Regards. hkoba. On 2014-5月-03 土 17:59:51, SREZIC wrote: Show quoted text

> YATT's test suite fails with newest perls (5.19.10, 5.19.11). > Following the beginning of the test log run: > > Output from './Build test': > > web/cgi-bin/yatt.lib/t/rlimit.t ........... skipped: BSD::Resource is > not installed > web/cgi-bin/yatt.lib/t/topcgi-redirect.t .. skipped: yatt.cgi and > testapp is not installed. > > # Failed test 'require YATT::Translator::Perl;' > # at web/cgi-bin/yatt.lib/t/use.t line 64. > # Tried to require 'YATT::Translator::Perl'. > # Error: No such class t_attr at /home/cpansand/.cpan/build/YATT- > v0.0.8-fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line > 1396, near "my t_attr" > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1396. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1397. > # No such class t_attr at /home/cpansand/.cpan/build/YATT-v0.0.8- > fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1402, > near "(my t_attr" > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1402. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1407. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1412. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1412. > # Global symbol "$var" requires explicit package name at > /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1413. > # No such class t_attr at /home/cpansand/.cpan/build/YATT-v0.0.8- > fpPXvw/web/cgi-bin/yatt.lib/t/../YATT/Translator/Perl.pm line 1417, > near "my t_attr" > # /home/cpansand/.cpan/build/YATT-v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl.pm has too many errors. > # Compilation failed in require at (eval 58) line 2. > > # Failed test 'require YATT::Translator::Perl::macro_dbfetch;' > # at web/cgi-bin/yatt.lib/t/use.t line 64. > # Tried to require 'YATT::Translator::Perl::macro_dbfetch'. > # Error: Attempt to reload YATT/Translator/Perl.pm aborted. > # Compilation failed in require at /home/cpansand/.cpan/build/YATT- > v0.0.8-fpPXvw/web/cgi- > bin/yatt.lib/t/../YATT/Translator/Perl/macro_dbfetch.pm line 4. > # Compilation failed in require at (eval 75) line 2. > # Looks like you failed 2 tests of 112. > web/cgi-bin/yatt.lib/t/use.t .............. > Dubious, test returned 2 (wstat 512, 0x200) > Failed 2/112 subtests > (less 6 skipped subtests: 104 okay) > ... > > > Regards, > Slaven

Subject:

typealias_ng.t

#!/usr/bin/env perl use strict; use warnings FATAL => qw/all/; sub make_type_alias { my $callpack = caller; foreach my $name (@_) { my $fullname = join("::", $callpack, $name); { local $@; eval "package $fullname"; die $@ if $@; } *{globref($fullname)} = sub () {$fullname}; } } sub globref { my $fullname = join "::", @_; do {no strict 'refs'; \*$fullname}; } use Test::More; my $common = <<'END'; package testing::dummy%d; sub MY () {__PACKAGE__} use strict; BEGIN {::make_type_alias(qw/Foo Bar Baz/)} END { my $script = sprintf($common, 1). <<'END'; sub t1 { join(", ", Foo); } 1; END ok eval($script), "use of constant sub"; is $@, '', "no error"; } { my $script = sprintf($common, 2). <<'END'; sub t2 { (my Foo $foo) = @_; } 1; END ok eval($script), "use of constant sub for my Dog \$spot"; is $@, '', "no error"; } { my $script = sprintf($common, 3). <<'END'; sub t3 { (my MY $foo) = @_; } 1; END ok eval($script), "use of constant sub for my Dog \$spot"; is $@, '', "no error"; } done_testing();

Mon May 05 18:16:34 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-05-05 06:24:29, HKOBA wrote: Show quoted text

> Thank you for telling me about this failure. > Could you/someone explain me about changes about constant sub handling > introduced between 5.19.2 and 5.19.3? > > I noticed attached test do not work after 5.19.3. > Is this intentional change? > > In YATT and other project, I've been used compile time checking with > > my Dog $spot = ... > > feature in conjunction with constant sub (in this case 'Dog'), > which is generated compile time. > > To generate constant sub ('Dog' => 'My::Lib::Dog'), I've been used > > my $sym = do {no strict 'refs'; \*$string}; > *$sym = sub () {$value}; > > > Is this obsoleted anymore? >

First, the change about sub(){$var} was documented in perl5193delta.pod: * Closures of the form "sub () { $some_variable }" are no longer inlined, causing changes to the variable to be ignored by callers of the subroutine. [perl #79908] As a consequence of this change it seems that creation of the sub still works, but it is not anymore an inlinable constant. If you need still to create a real constant, you can use a string-eval hack like this: *{globref($fullname)} = eval "sub () {q{$fullname}}"; die $@ if $@; However, probably it's best to ask directly at the perl5-porters mailing list for advise. Regards, Slaven

Mon May 05 22:26:24 2014 hkoba [...] cpan.org - Correspondence added

Thank you for your explanation of the change and workaround. Although your advice is enough good for me, I too think I should ask p5p for advice about this, especially about 1. Why this change is required. 2. What is recommended way to dynamically make inlineable subs. # But for me, writing in English is not so easy, so please wait. Thanks! hkoba. On 2014-5月-06 火 07:16:34, SREZIC wrote: Show quoted text

> On 2014-05-05 06:24:29, HKOBA wrote:

> > Thank you for telling me about this failure. > > Could you/someone explain me about changes about constant sub > > handling > > introduced between 5.19.2 and 5.19.3? > > > > I noticed attached test do not work after 5.19.3. > > Is this intentional change? > > > > In YATT and other project, I've been used compile time checking with > > > > my Dog $spot = ... > > > > feature in conjunction with constant sub (in this case 'Dog'), > > which is generated compile time. > > > > To generate constant sub ('Dog' => 'My::Lib::Dog'), I've been used > > > > my $sym = do {no strict 'refs'; \*$string}; > > *$sym = sub () {$value}; > > > > > > Is this obsoleted anymore? > >

> > First, the change about sub(){$var} was documented in > perl5193delta.pod: > > * Closures of the form "sub () { $some_variable }" are no longer > inlined, causing changes to the variable to be ignored by callers > of > the subroutine. [perl #79908] > > As a consequence of this change it seems that creation of the sub > still works, but it is not anymore an inlinable constant. If you need > still to create a real constant, you can use a string-eval hack like > this: > > *{globref($fullname)} = eval "sub () {q{$fullname}}"; die $@ if $@; > > However, probably it's best to ask directly at the perl5-porters > mailing list for advise. > > Regards, > Slaven

Mon May 05 22:59:14 2014 hkoba [...] cpan.org - Taken

Fri May 09 03:26:49 2014 hkoba [...] cpan.org - Correspondence added

Hi, May I ask you about current status of following patch? * smoke-me/avar/rv-fix-79908 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 Is above patch judged to go into mainline? or Is it rejected? Do I still need to change YATT to solve this ticket #95311 ? Thanks. hkoba On 2014-5月-06 火 07:16:34, SREZIC wrote: Show quoted text

> On 2014-05-05 06:24:29, HKOBA wrote:

> > Thank you for telling me about this failure. > > Could you/someone explain me about changes about constant sub > > handling > > introduced between 5.19.2 and 5.19.3? > > > > I noticed attached test do not work after 5.19.3. > > Is this intentional change? > > > > In YATT and other project, I've been used compile time checking with > > > > my Dog $spot = ... > > > > feature in conjunction with constant sub (in this case 'Dog'), > > which is generated compile time. > > > > To generate constant sub ('Dog' => 'My::Lib::Dog'), I've been used > > > > my $sym = do {no strict 'refs'; \*$string}; > > *$sym = sub () {$value}; > > > > > > Is this obsoleted anymore? > >

> > First, the change about sub(){$var} was documented in > perl5193delta.pod: > > * Closures of the form "sub () { $some_variable }" are no longer > inlined, causing changes to the variable to be ignored by callers > of > the subroutine. [perl #79908] > > As a consequence of this change it seems that creation of the sub > still works, but it is not anymore an inlinable constant. If you need > still to create a real constant, you can use a string-eval hack like > this: > > *{globref($fullname)} = eval "sub () {q{$fullname}}"; die $@ if $@; > > However, probably it's best to ask directly at the perl5-porters > mailing list for advise. > > Regards, > Slaven

Fri May 09 13:50:57 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-05-09 03:26:49, HKOBA wrote: Show quoted text

> Hi, > > May I ask you about current status of following patch? > > * smoke-me/avar/rv-fix-79908 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 > > Is above patch judged to go into mainline? or Is it rejected? > > Do I still need to change YATT to solve this ticket #95311 ? >

Sorry, I can't tell. It's best if you ask again in the thread you opened in perl5-porters. Regards, Slaven Show quoted text

> Thanks. > hkoba > > > On 2014-5月-06 火 07:16:34, SREZIC wrote:

> > On 2014-05-05 06:24:29, HKOBA wrote:

> > > Thank you for telling me about this failure. > > > Could you/someone explain me about changes about constant sub > > > handling > > > introduced between 5.19.2 and 5.19.3? > > > > > > I noticed attached test do not work after 5.19.3. > > > Is this intentional change? > > > > > > In YATT and other project, I've been used compile time checking with > > > > > > my Dog $spot = ... > > > > > > feature in conjunction with constant sub (in this case 'Dog'), > > > which is generated compile time. > > > > > > To generate constant sub ('Dog' => 'My::Lib::Dog'), I've been used > > > > > > my $sym = do {no strict 'refs'; \*$string}; > > > *$sym = sub () {$value}; > > > > > > > > > Is this obsoleted anymore? > > >

> > > > First, the change about sub(){$var} was documented in > > perl5193delta.pod: > > > > * Closures of the form "sub () { $some_variable }" are no longer > > inlined, causing changes to the variable to be ignored by callers > > of > > the subroutine. [perl #79908] > > > > As a consequence of this change it seems that creation of the sub > > still works, but it is not anymore an inlinable constant. If you need > > still to create a real constant, you can use a string-eval hack like > > this: > > > > *{globref($fullname)} = eval "sub () {q{$fullname}}"; die $@ if $@; > > > > However, probably it's best to ask directly at the perl5-porters > > mailing list for advise. > > > > Regards, > > Slaven

> >

Wed Apr 01 20:58:19 2015 TONYC [...] cpan.org - Correspondence added

On Fri May 09 03:26:49 2014, HKOBA wrote: Show quoted text

> Hi, > > May I ask you about current status of following patch? > > * smoke-me/avar/rv-fix-79908 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 > > Is above patch judged to go into mainline? or Is it rejected? > > Do I still need to change YATT to solve this ticket #95311 ?

You still need to modify YATT. The behaviour has changed in 5.21.x, the following code: my $value = ...; *foo = sub () { $value }; will generate a constant, but if you do anything with the value variable that *might* modify it a constant will not be generated, so for instance with your: sub make_type_alias { my $callpack = caller; foreach my $name (@_) { my $fullname = join("::", $callpack, $name); { local $@; eval "package $fullname"; die $@ if $@; } *{globref($fullname)} = sub () {$fullname}; } } the reference to $fullname in: globref($fullname) will prevent a const sub from being created, since globref() could potentially modify $fullname, or create a reference to it for later modification. This can be fixed by making sure the only use of the variable used for the constant is in its initialization, so make_type_alias() becomes: sub make_type_alias { my $callpack = caller; foreach my $name (@_) { my $fullname = join("::", $callpack, $name); { local $@; eval "package $fullname"; die $@ if $@; } my $const_value = $fullname; *{globref($fullname)} = sub () {$const_value}; } } which allows your tests to pass: $ ./perl -Ilib ../yatt-issue-sample.pl ok 1 - use of constant sub ok 2 - no error ok 3 - use of constant sub for my Dog $spot ok 4 - no error ok 5 - use of constant sub for my Dog $spot ok 6 - no error 1..6 Note that declaring the variable and then setting it: my $value; $value = ...; *foo = sub () { $value }; won't result in a constant, see: http://perl5.git.perl.org/perl.git/blob/v5.21.6:/pod/perldelta.pod#l54 for the full details. You asked: Show quoted text

> 1. Why this change is required.

See https://rt.perl.org/Ticket/Display.html?id=79908 for the details, but as a summary, the problem was that: sub () { $foo } and sub () { return $foo } could behave differently with the old implementation, if $foo was modified somewhere. The behaviour was documented, but if you didn't know about the non-intuitive behaviour it could be confusing. With the change only subs that where the variable can't be modified will be inlined, meaning the behaviour wouldn't change with the inlining optimization. Tony

Wed Apr 01 21:16:35 2015 hkoba [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #95311] Test suite fails with perl 5.19.x
Date:	Thu, 2 Apr 2015 10:16:23 +0900
To:	bug-YATT [...] rt.cpan.org
From:	KOBAYASI hiroaki <hkoba [...] cpan.org>

Hi, Thank you for your deep inspection of my code and detailed great explanation about this perl5.21.x change! I will fix YATT and YATT::Lite. Thank you!! hkoba. 2015-04-02 9:58 GMT+09:00 TONYC via RT <bug-YATT@rt.cpan.org>: Show quoted text

> Queue: YATT > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95311 > > > On Fri May 09 03:26:49 2014, HKOBA wrote:

>> Hi, >> >> May I ask you about current status of following patch? >> >> * smoke-me/avar/rv-fix-79908 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 >> >> Is above patch judged to go into mainline? or Is it rejected? >> >> Do I still need to change YATT to solve this ticket #95311 ?

> > You still need to modify YATT. > > The behaviour has changed in 5.21.x, the following code: > > my $value = ...; > *foo = sub () { $value }; > > will generate a constant, but if you do anything with the value variable that > *might* modify it a constant will not be generated, so for instance with your: > > sub make_type_alias { > my $callpack = caller; > foreach my $name (@_) { > my $fullname = join("::", $callpack, $name); > { > local $@; eval "package $fullname"; die $@ if $@; > } > *{globref($fullname)} = sub () {$fullname}; > } > } > > the reference to $fullname in: > > globref($fullname) > > will prevent a const sub from being created, since globref() could potentially > modify $fullname, or create a reference to it for later modification. > > This can be fixed by making sure the only use of the variable used for the > constant is in its initialization, so make_type_alias() becomes: > > sub make_type_alias { > my $callpack = caller; > foreach my $name (@_) { > my $fullname = join("::", $callpack, $name); > { > local $@; eval "package $fullname"; die $@ if $@; > } > my $const_value = $fullname; > *{globref($fullname)} = sub () {$const_value}; > } > } > > which allows your tests to pass: > > $ ./perl -Ilib ../yatt-issue-sample.pl > ok 1 - use of constant sub > ok 2 - no error > ok 3 - use of constant sub for my Dog $spot > ok 4 - no error > ok 5 - use of constant sub for my Dog $spot > ok 6 - no error > 1..6 > > Note that declaring the variable and then setting it: > > my $value; > $value = ...; > *foo = sub () { $value }; > > won't result in a constant, see: > > http://perl5.git.perl.org/perl.git/blob/v5.21.6:/pod/perldelta.pod#l54 > > for the full details. > > You asked: >

>> 1. Why this change is required.

> > See https://rt.perl.org/Ticket/Display.html?id=79908 for the details, but as a > summary, the problem was that: > > sub () { $foo } > > and > > sub () { return $foo } > > could behave differently with the old implementation, if $foo was modified somewhere. > > The behaviour was documented, but if you didn't know about the non-intuitive behaviour > it could be confusing. > > With the change only subs that where the variable can't be modified will be inlined, > meaning the behaviour wouldn't change with the inlining optimization. > > Tony

Sat Apr 11 20:32:26 2015 hkoba [...] cpan.org - Correspondence added

I hope this is fixed! Thank you all for all of advices! On 2015-4月-02 木 10:16:35, HKOBA wrote: Show quoted text

> Hi, > > Thank you for your deep inspection of my code and detailed great > explanation about this perl5.21.x change! > I will fix YATT and YATT::Lite. > > Thank you!! > > hkoba. > > > 2015-04-02 9:58 GMT+09:00 TONYC via RT <bug-YATT@rt.cpan.org>:

> > Queue: YATT > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95311 > > > > > On Fri May 09 03:26:49 2014, HKOBA wrote:

> >> Hi, > >> > >> May I ask you about current status of following patch? > >> > >> * smoke-me/avar/rv-fix-79908 > >> 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 > >> > >> Is above patch judged to go into mainline? or Is it rejected? > >> > >> Do I still need to change YATT to solve this ticket #95311 ?

> > > > You still need to modify YATT. > > > > The behaviour has changed in 5.21.x, the following code: > > > > my $value = ...; > > *foo = sub () { $value }; > > > > will generate a constant, but if you do anything with the value > > variable that > > *might* modify it a constant will not be generated, so for instance > > with your: > > > > sub make_type_alias { > > my $callpack = caller; > > foreach my $name (@_) { > > my $fullname = join("::", $callpack, $name); > > { > > local $@; eval "package $fullname"; die $@ if $@; > > } > > *{globref($fullname)} = sub () {$fullname}; > > } > > } > > > > the reference to $fullname in: > > > > globref($fullname) > > > > will prevent a const sub from being created, since globref() could > > potentially > > modify $fullname, or create a reference to it for later modification. > > > > This can be fixed by making sure the only use of the variable used > > for the > > constant is in its initialization, so make_type_alias() becomes: > > > > sub make_type_alias { > > my $callpack = caller; > > foreach my $name (@_) { > > my $fullname = join("::", $callpack, $name); > > { > > local $@; eval "package $fullname"; die $@ if $@; > > } > > my $const_value = $fullname; > > *{globref($fullname)} = sub () {$const_value}; > > } > > } > > > > which allows your tests to pass: > > > > $ ./perl -Ilib ../yatt-issue-sample.pl > > ok 1 - use of constant sub > > ok 2 - no error > > ok 3 - use of constant sub for my Dog $spot > > ok 4 - no error > > ok 5 - use of constant sub for my Dog $spot > > ok 6 - no error > > 1..6 > > > > Note that declaring the variable and then setting it: > > > > my $value; > > $value = ...; > > *foo = sub () { $value }; > > > > won't result in a constant, see: > > > > http://perl5.git.perl.org/perl.git/blob/v5.21.6:/pod/perldelta.pod#l54 > > > > for the full details. > > > > You asked: > >

> >> 1. Why this change is required.

> > > > See https://rt.perl.org/Ticket/Display.html?id=79908 for the details, > > but as a > > summary, the problem was that: > > > > sub () { $foo } > > > > and > > > > sub () { return $foo } > > > > could behave differently with the old implementation, if $foo was > > modified somewhere. > > > > The behaviour was documented, but if you didn't know about the non- > > intuitive behaviour > > it could be confusing. > > > > With the change only subs that where the variable can't be modified > > will be inlined, > > meaning the behaviour wouldn't change with the inlining optimization. > > > > Tony

Sat Apr 11 20:32:27 2015 hkoba [...] cpan.org - Status changed from 'open' to 'patched'

Sat Apr 11 20:32:28 2015 hkoba [...] cpan.org - Fixed in 0.0_9 added

Sat Nov 07 05:06:08 2015 SREZIC [...] cpan.org - Correspondence added

The most recent devel version looks better wrt perl 5.21.x and newer, so maybe a new stable release could be done out of it? Test overview: http://matrix.cpantesters.org/?dist=YATT%200.0_9 On 2015-04-11 20:32:26, HKOBA wrote: Show quoted text

> I hope this is fixed! Thank you all for all of advices! > > On 2015-4月-02 木 10:16:35, HKOBA wrote:

> > Hi, > > > > Thank you for your deep inspection of my code and detailed great > > explanation about this perl5.21.x change! > > I will fix YATT and YATT::Lite. > > > > Thank you!! > > > > hkoba. > > > > > > 2015-04-02 9:58 GMT+09:00 TONYC via RT <bug-YATT@rt.cpan.org>:

> > > Queue: YATT > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95311 > > > > > > > On Fri May 09 03:26:49 2014, HKOBA wrote:

> > >> Hi, > > >> > > >> May I ask you about current status of following patch? > > >> > > >> * smoke-me/avar/rv-fix-79908 > > >> 45558e2060d49c463cdc10e07f8ff1c8e5d72cd4 > > >> > > >> Is above patch judged to go into mainline? or Is it rejected? > > >> > > >> Do I still need to change YATT to solve this ticket #95311 ?

> > > > > > You still need to modify YATT. > > > > > > The behaviour has changed in 5.21.x, the following code: > > > > > > my $value = ...; > > > *foo = sub () { $value }; > > > > > > will generate a constant, but if you do anything with the value > > > variable that > > > *might* modify it a constant will not be generated, so for instance > > > with your: > > > > > > sub make_type_alias { > > > my $callpack = caller; > > > foreach my $name (@_) { > > > my $fullname = join("::", $callpack, $name); > > > { > > > local $@; eval "package $fullname"; die $@ if $@; > > > } > > > *{globref($fullname)} = sub () {$fullname}; > > > } > > > } > > > > > > the reference to $fullname in: > > > > > > globref($fullname) > > > > > > will prevent a const sub from being created, since globref() could > > > potentially > > > modify $fullname, or create a reference to it for later modification. > > > > > > This can be fixed by making sure the only use of the variable used > > > for the > > > constant is in its initialization, so make_type_alias() becomes: > > > > > > sub make_type_alias { > > > my $callpack = caller; > > > foreach my $name (@_) { > > > my $fullname = join("::", $callpack, $name); > > > { > > > local $@; eval "package $fullname"; die $@ if $@; > > > } > > > my $const_value = $fullname; > > > *{globref($fullname)} = sub () {$const_value}; > > > } > > > } > > > > > > which allows your tests to pass: > > > > > > $ ./perl -Ilib ../yatt-issue-sample.pl > > > ok 1 - use of constant sub > > > ok 2 - no error > > > ok 3 - use of constant sub for my Dog $spot > > > ok 4 - no error > > > ok 5 - use of constant sub for my Dog $spot > > > ok 6 - no error > > > 1..6 > > > > > > Note that declaring the variable and then setting it: > > > > > > my $value; > > > $value = ...; > > > *foo = sub () { $value }; > > > > > > won't result in a constant, see: > > > > > > http://perl5.git.perl.org/perl.git/blob/v5.21.6:/pod/perldelta.pod#l54 > > > > > > for the full details. > > > > > > You asked: > > >

> > >> 1. Why this change is required.

> > > > > > See https://rt.perl.org/Ticket/Display.html?id=79908 for the details, > > > but as a > > > summary, the problem was that: > > > > > > sub () { $foo } > > > > > > and > > > > > > sub () { return $foo } > > > > > > could behave differently with the old implementation, if $foo was > > > modified somewhere. > > > > > > The behaviour was documented, but if you didn't know about the non- > > > intuitive behaviour > > > it could be confusing. > > > > > > With the change only subs that where the variable can't be modified > > > will be inlined, > > > meaning the behaviour wouldn't change with the inlining optimization. > > > > > > Tony

> >