New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Not a GLOB reference" 5.10.1 vs. 5.11.3 #10075
Comments
From @kmxHi, I am not sure if this is a bug in perl core or in namespace::clean, but Let us have perl 5.11.3 + namespace::clean 0.11 and create a module package XX; Then: C:\> perl -e "use XX" It does not happen on perl 5.10.1. Anyway it is currently a blocker for Catalyst::Runtime on perl 5.11.3. The same issue is already reported here (on different platforms): -- Perl Info
|
From p5p@perl.wizbit.beCiteren kmx <perlbug-followup@perl.org>:
Core only test case: #!/usr/bin/perl -l package XX; BEGIN { print $]; } use Symbol qw( qualify_to_ref ); use Socket ("AF_INET"); BEGIN { BEGIN { my $z = AF_INET; BEGIN { __END__ Running it with: and old blead (GitLive-blead-2508-g0d4cbbc) and a 5.011000 5.011003 Best regards, Bram |
The RT System itself - Status changed from 'new' to 'open' |
From @kmxDne út 12.led.2010 14:08:31, p5p@perl.wizbit.be napsal(a):
Dne út 12.led.2010 18:28:06, rafl napsal(a):
So is this RT one that "SHOULD BLOCK 5.12"? -- |
From zefram@fysh.orgkmx wrote:
rafl reports, as I suspected, that the core change causing this is I can provide a patch for ns:c. (But I'll feel all dirty working on it. -zefram |
From zefram@fysh.orgPatch for namespace::clean is attached. -zefram |
From zefram@fysh.orgInline Patchdiff -urN namespace-clean-0.11.orig/MANIFEST namespace-clean-0.11.mod0/MANIFEST
--- namespace-clean-0.11.orig/MANIFEST 2009-03-03 16:38:24.000000000 +0000
+++ namespace-clean-0.11.mod0/MANIFEST 2010-01-13 20:19:20.000000000 +0000
@@ -21,6 +21,7 @@
t/03-unimport.t
t/04-except.t
t/05-explicit-cleanee.t
+t/06-const-sub.t
t/lib/CleaneeBridge.pm
t/lib/CleaneeBridgeDirect.pm
t/lib/CleaneeBridgeExplicit.pm
diff -urN namespace-clean-0.11.orig/lib/namespace/clean.pm namespace-clean-0.11.mod0/lib/namespace/clean.pm
--- namespace-clean-0.11.orig/lib/namespace/clean.pm 2009-03-03 16:30:30.000000000 +0000
+++ namespace-clean-0.11.mod0/lib/namespace/clean.pm 2010-01-13 20:35:28.000000000 +0000
@@ -166,17 +166,27 @@
next SYMBOL if $store->{exclude}{ $f };
no strict 'refs';
- # keep original value to restore non-code slots
- { no warnings 'uninitialized'; # fix possible unimports
- local *__tmp = *{ ${ "${cleanee}::" }{ $f } };
- delete ${ "${cleanee}::" }{ $f };
- }
+ next SYMBOL unless exists ${ "${cleanee}::" }{ $f };
- SLOT:
- # restore non-code slots to symbol
- for my $t (qw( SCALAR ARRAY HASH IO FORMAT )) {
- next SLOT unless defined *__tmp{ $t };
- *{ "${cleanee}::$f" } = *__tmp{ $t };
+ if (ref(\${ "${cleanee}::" }{ $f }) eq "GLOB") {
+ # keep original value to restore non-code slots
+ { no warnings 'uninitialized'; # fix possible unimports
+ local *__tmp = *{ ${ "${cleanee}::" }{ $f } };
+ delete ${ "${cleanee}::" }{ $f };
+ }
+
+ SLOT:
+ # restore non-code slots to symbol
+ for my $t (qw( SCALAR ARRAY HASH IO FORMAT )) {
+ next SLOT unless defined *__tmp{ $t };
+ *{ "${cleanee}::$f" } = *__tmp{ $t };
+ }
+ }
+ else {
+ # A non-glob in the stash is assumed to stand for some kind
+ # of function. So far they all do, but the core might change
+ # this some day. Watch perl5-porters.
+ delete ${ "${cleanee}::" }{ $f };
}
}
};
diff -urN namespace-clean-0.11.orig/t/06-const-sub.t namespace-clean-0.11.mod0/t/06-const-sub.t
--- namespace-clean-0.11.orig/t/06-const-sub.t 1970-01-01 01:00:00.000000000 +0100
+++ namespace-clean-0.11.mod0/t/06-const-sub.t 2010-01-13 20:17:57.000000000 +0000
@@ -0,0 +1,11 @@
+#!/usr/bin/env perl
+use warnings;
+use strict;
+
+use Test::More tests => 2;
+
+use constant CONST => 123;
+use namespace::clean;
+my $x = CONST;
+is $x, 123;
+ok eval("!defined(&CONST)"); |
From @rgsI'm marking this bug as resolved, since it's a matter of adapting |
@rgs - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#72038 (status was 'resolved')
Searchable as RT72038$
The text was updated successfully, but these errors were encountered: