Skip Menu |
Report information
Id: 131679
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: ishigaki <ishigaki [at] cpan.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.26.0
Fixed In: (no value)



Subject: our sub Foo::Bar spits a different error message from the one for my sub Foo::Bar
To: perlbug [...] perl.org
CC: ishigaki [...] cpan.org
From: ishigaki [...] cpan.org
Date: Fri, 30 Jun 2017 16:37:54 +0900 (JST)
Download (untitled) / with headers
text/plain 3.8k
This is a bug report for perl from ishigaki@cpan.org, generated with the help of perlbug 1.40 running under perl 5.26.0. ----------------------------------------------------------------- [Please describe your issue here] our sub Foo::Bar spits a different error message from the one for my sub Foo::Bar or state sub Foo::Bar, which seems a little odd. See the following examples: $ perl -E 'my sub Foo::Bar {}' "my" subroutine &Foo::Bar can't be in a package at -e line 1, near "my sub Foo::Bar" $ perl -E 'state sub Foo::Bar {}' "state" subroutine &Foo::Bar can't be in a package at -e line 1, near "state sub Foo::Bar" $ perl -E 'our sub Foo::Bar {}' No package name allowed for variable &Foo::Bar in "our" at -e line 1, near "our sub Foo::Bar" [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.26.0: Configured by ishigaki at Wed May 31 14:15:00 JST 2017. Summary of my perl5 (revision 5 version 26 subversion 0) configuration: Platform: osname=linux osvers=3.16.0-4-amd64 archname=x86_64-linux uname='linux charsbar.org 3.16.0-4-amd64 #1 smp debian 3.16.39-1 (2016-12-30) x86_64 gnulinux ' config_args='-Dprefix=/home/ishigaki/.plenv/versions/5.26.0 -de -Dusedevel -A'eval:scriptdir=/home/ishigaki/.plenv/versions/5.26.0/bin'' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2' cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='4.9.2' 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='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.19.so so=so useshrplib=false libperl=libperl.a gnulibc_version='2.19' 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' Locally applied patches: Devel::PatchPerl 1.48 --- @INC for perl 5.26.0: /home/ishigaki/.plenv/versions/5.26.0/lib/perl5/site_perl/5.26.0/x86_64-linux /home/ishigaki/.plenv/versions/5.26.0/lib/perl5/site_perl/5.26.0 /home/ishigaki/.plenv/versions/5.26.0/lib/perl5/5.26.0/x86_64-linux /home/ishigaki/.plenv/versions/5.26.0/lib/perl5/5.26.0 --- Environment for perl 5.26.0: HOME=/home/ishigaki LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/ishigaki/.plenv/versions/5.26.0/bin:/home/ishigaki/.plenv/libexec:/home/ishigaki/.plenv/plugins/perl-build/bin:/home/ishigaki/.rakudobrew/bin:/home/ishigaki/.rbenv/shims:/home/ishigaki/.rbenv/bin:/home/ishigaki/.plenv/shims:/home/ishigaki/.plenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PERL_BADLANG (unset) SHELL=/bin/bash
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Fri, 30 Jun 2017 00:38:00 -0700, ishigaki wrote: Show quoted text
> > This is a bug report for perl from ishigaki@cpan.org, > generated with the help of perlbug 1.40 running under perl 5.26.0. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > our sub Foo::Bar spits a different error message from the one for > my sub Foo::Bar or state sub Foo::Bar, which seems a little odd. > > See the following examples: > > $ perl -E 'my sub Foo::Bar {}' > "my" subroutine &Foo::Bar can't be in a package at -e line 1, near "my > sub Foo::Bar" > > $ perl -E 'state sub Foo::Bar {}' > "state" subroutine &Foo::Bar can't be in a package at -e line 1, near > "state sub Foo::Bar" > > $ perl -E 'our sub Foo::Bar {}' > No package name allowed for variable &Foo::Bar in "our" at -e line 1, > near "our sub Foo::Bar"
That it says ‘variable’, not ‘subroutine’, is a bug. That is emits a different message is longstanding behaviour, based on variables: $ perl -e 'my $foo::bar' "my" variable $foo::bar can't be in a package at -e line 1, near "my $foo::bar " Execution of -e aborted due to compilation errors. $ perl -e 'our $foo::bar' No package name allowed for variable $foo::bar in "our" at -e line 1, near "our $foo::bar " Execution of -e aborted due to compilation errors. I think the difference is due to the fact that ‘our’ variables do reside in a package; they just cannot be declared that way. -- Father Chrysostomos
Subject: Re: [perl #131679] our sub Foo::Bar spits a different error message from the one for my sub Foo::Bar
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Date: Fri, 30 Jun 2017 15:29:41 +0200
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k


On 30 Jun 2017 15:18, "Father Chrysostomos via RT" <perlbug-followup@perl.org> wrote:
Show quoted text
On Fri, 30 Jun 2017 00:38:00 -0700, ishigaki wrote:
>
> This is a bug report for perl from ishigaki@cpan.org,
> generated with the help of perlbug 1.40 running under perl 5.26.0.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> our sub Foo::Bar spits a different error message from the one for
> my sub Foo::Bar or state sub Foo::Bar, which seems a little odd.
>
> See the following examples:
>
> $ perl -E 'my sub Foo::Bar {}'
> "my" subroutine &Foo::Bar can't be in a package at -e line 1, near "my
> sub Foo::Bar"
>
> $ perl -E 'state sub Foo::Bar {}'
> "state" subroutine &Foo::Bar can't be in a package at -e line 1, near
> "state sub Foo::Bar"
>
> $ perl -E 'our sub Foo::Bar {}'
> No package name allowed for variable &Foo::Bar in "our" at -e line 1,
> near "our sub Foo::Bar"

That it says ‘variable’, not ‘subroutine’, is a bug.  That is emits a different message is longstanding behaviour, based on variables:

$ perl -e 'my $foo::bar'
"my" variable $foo::bar can't be in a package at -e line 1, near "my $foo::bar
"
Execution of -e aborted due to compilation errors.
$ perl -e 'our $foo::bar'
No package name allowed for variable $foo::bar in "our" at -e line 1, near "our $foo::bar
"
Execution of -e aborted due to compilation errors.

I think the difference is due to the fact that ‘our’ variables do reside in a package; they just cannot be declared that way.

It doesn't make sense to use our with a fully qualified var; what would it even mean? 

Yves
Show quoted text

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Fri, 30 Jun 2017 06:31:26 -0700, demerphq wrote: Show quoted text
> On 30 Jun 2017 15:18, "Father Chrysostomos via RT" < > perlbug-followup@perl.org> wrote: > > On Fri, 30 Jun 2017 00:38:00 -0700, ishigaki wrote:
> > > > This is a bug report for perl from ishigaki@cpan.org, > > generated with the help of perlbug 1.40 running under perl 5.26.0. > > > > > > ----------------------------------------------------------------- > > [Please describe your issue here] > > > > our sub Foo::Bar spits a different error message from the one for > > my sub Foo::Bar or state sub Foo::Bar, which seems a little odd. > > > > See the following examples: > > > > $ perl -E 'my sub Foo::Bar {}' > > "my" subroutine &Foo::Bar can't be in a package at -e line 1, near "my > > sub Foo::Bar" > > > > $ perl -E 'state sub Foo::Bar {}' > > "state" subroutine &Foo::Bar can't be in a package at -e line 1, near > > "state sub Foo::Bar" > > > > $ perl -E 'our sub Foo::Bar {}' > > No package name allowed for variable &Foo::Bar in "our" at -e line 1, > > near "our sub Foo::Bar"
> > That it says ‘variable’, not ‘subroutine’, is a bug. That is emits a > different message is longstanding behaviour, based on variables: > > $ perl -e 'my $foo::bar' > "my" variable $foo::bar can't be in a package at -e line 1, near "my > $foo::bar > " > Execution of -e aborted due to compilation errors. > $ perl -e 'our $foo::bar' > No package name allowed for variable $foo::bar in "our" at -e line 1, near > "our $foo::bar > " > Execution of -e aborted due to compilation errors. > > I think the difference is due to the fact that ‘our’ variables do reside in > a package; they just cannot be declared that way. > > > It doesn't make sense to use our with a fully qualified var; what would it > even mean?
I wrote it out of mere curiosity while I was checking what lexical subs could do and could not do, to prepare for a talk I gave at YAPC::Japan this morning: "my sub ok" can be used, for example, to monkey-patch "ok" imported from Test::More only in some block and without disabling warnings. Let's see, then, if it can also be used to monkey-patch Test::More::ok itself. Of course not. Then what happens if I change "my" to something else, and oh... So, I also don't know what it should mean. However, I was surprised when I saw the word "variable" while testing lexical subroutine, hence the report. Show quoted text
> > Yves
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 275b
On Fri, 30 Jun 2017 23:42:27 -0700, ishigaki wrote: Show quoted text
> So, I also don't know what it should mean. However, I was surprised > when I saw the word "variable" while testing lexical subroutine, hence > the report.
This is now fixed in commit b9a58d500. -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org