Skip to content
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

our sub Foo::Bar spits a different error message from the one for my sub Foo::Bar #16058

Closed
p5pRT opened this issue Jun 30, 2017 · 9 comments
Closed

Comments

@p5pRT
Copy link

p5pRT commented Jun 30, 2017

Migrated from rt.perl.org#131679 (status was 'resolved')

Searchable as RT131679$

@p5pRT
Copy link
Author

p5pRT commented Jun 30, 2017

From ishigaki@cpan.org

Created by ishigaki@cpan.org

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"

Perl Info

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

@p5pRT
Copy link
Author

p5pRT commented Jun 30, 2017

From @cpansprout

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.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jun 30, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 30, 2017

From @demerphq

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?

Yves

@p5pRT
Copy link
Author

p5pRT commented Jul 1, 2017

From ishigaki@cpan.org

On Fri, 30 Jun 2017 06​:31​:26 -0700, demerphq wrote​:

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.

Yves

@p5pRT
Copy link
Author

p5pRT commented Jul 2, 2017

From @cpansprout

On Fri, 30 Jun 2017 23​:42​:27 -0700, ishigaki wrote​:

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 b9a58d5.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jul 2, 2017

@cpansprout - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant