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

Unexpected syntax error #15933

Open
p5pRT opened this issue Mar 26, 2017 · 12 comments
Open

Unexpected syntax error #15933

p5pRT opened this issue Mar 26, 2017 · 12 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 26, 2017

Migrated from rt.perl.org#131062 (status was 'open')

Searchable as RT131062$

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

From @KES777

Created by @KES777

$ perl -e '$xx ||= 3'

$ perl -MO=Concise -e '$xx ||= 3'
7 <@​> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v​:{ ->3
- <1> null vK/1 ->7
4 <|> orassign(other->5) vK/1 ->7
- <1> ex-rv2sv sKRM/1 ->4
3 <$> gvsv(*xx) s ->4
6 <1> sassign sK/BKWARD,1 ->7
5 <$> const(IV 3) s ->6
-e syntax OK

$ perl -MO=Concise=-debug -e '$xx ||= 3'
syntax error at (eval 2) line 18, near "="
BEGIN failed--compilation aborted.

When I try to walk ops tree in debug mode I got syntax error.
While other mode works well

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.24.0:

Configured by kes at Wed Oct 19 14:07:47 EEST 2016.

Summary of my perl5 (revision 5 version 24 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=4.4.0-43-generic, archname=x86_64-linux
    uname='linux work 4.4.0-43-generic #63-ubuntu smp wed oct 12 13:48:03 utc 2016 x86_64 x86_64 x86_64 gnulinux '
    config_args='-de -Dprefix=/home/kes/perl5/perlbrew/perls/perl-5.24.0 -Aeval:scriptdir=/home/kes/perl5/perlbrew/perls/perl-5.24.0/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, 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',
    optimize='-O2',
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion='', gccversion='5.4.0 20160609', 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/5/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 /lib64 /usr/lib64
    libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.23.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.23'
  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.38


@INC for perl 5.24.0:
    /home/kes/work/projects/artcoin.io/artcoin/lib
    /home/kes/work/projects/artcoin.io/artcoin/local/lib/perl5/x86_64-linux
    /home/kes/work/projects/artcoin.io/artcoin/local/lib/perl5
    /home/kes/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/x86_64-linux
    /home/kes/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0
    /home/kes/perl5/perlbrew/perls/perl-5.24.0/lib/5.24.0/x86_64-linux
    /home/kes/perl5/perlbrew/perls/perl-5.24.0/lib/5.24.0
    .


Environment for perl 5.24.0:
    HOME=/home/kes
    LANG=en_US.UTF-8
    LANGUAGE=en
    LC_ADDRESS=uk_UA.UTF-8
    LC_IDENTIFICATION=uk_UA.UTF-8
    LC_MEASUREMENT=uk_UA.UTF-8
    LC_MESSAGES=en_US.UTF-8
    LC_MONETARY=uk_UA.UTF-8
    LC_NAME=uk_UA.UTF-8
    LC_NUMERIC=uk_UA.UTF-8
    LC_PAPER=uk_UA.UTF-8
    LC_TELEPHONE=uk_UA.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/kes/perl5/perlbrew/bin:/home/kes/perl5/perlbrew/perls/perl-5.24.0/bin:/home/kes/bin:/home/kes/bin:/home/kes/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
    PERL5DB=use Devel::DebugHooks::Terminal
    PERL5LIB=/home/kes/work/projects/artcoin.io/artcoin/lib:/home/kes/work/projects/artcoin.io/artcoin/local/lib/perl5
    PERLBREW=command perlbrew
    PERLBREW_BASHRC_VERSION=0.78
    PERLBREW_HOME=/home/kes/.perlbrew
    PERLBREW_MANPATH=/home/kes/perl5/perlbrew/perls/perl-5.24.0/man
    PERLBREW_PATH=/home/kes/perl5/perlbrew/bin:/home/kes/perl5/perlbrew/perls/perl-5.24.0/bin
    PERLBREW_PERL=perl-5.24.0
    PERLBREW_ROOT=/home/kes/perl5/perlbrew
    PERLBREW_VERSION=0.78
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

From @ilmari

KES (via RT) <perlbug-followup@​perl.org> writes​:

$ perl -MO=Concise=-debug -e '$xx ||= 3'
syntax error at (eval 2) line 18, near "="
BEGIN failed--compilation aborted.

This has nothing to do with B​::Concise, but the fact that you are using
the wrong syntax for -MO. -MO=Concise=-debug is equivalent to

  use O 'Concise=-debug';

which O to try to use "B​::Concise=-debug" as the name of the backend
module in a "use" inside a string eval, which causes the syntax error.

If you do -MO=Concise,-debug, which is equivalent to

  use O qw(Concise -debug);

it works. This is shown in the B​::Concise synopsis​:

  perl -MO=Concise[,OPTIONS] foo.pl

Note there's a comma before OPTIONS, not an equal sign.

- ilmari

--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

From @KES777

ah, comma. Thank you.

is it possible/reasonable to improve error message here?

26.03.2017, 15​:54, "Dagfinn Ilmari Mannsåker via RT" <perlbug-followup@​perl.org>​:

KES (via RT) <perlbug-followup@​perl.org> writes​:

 $ perl -MO=Concise=-debug -e '$xx ||= 3'
 syntax error at (eval 2) line 18, near "="
 BEGIN failed--compilation aborted.

This has nothing to do with B​::Concise, but the fact that you are using
the wrong syntax for -MO. -MO=Concise=-debug is equivalent to

    use O 'Concise=-debug';

which O to try to use "B​::Concise=-debug" as the name of the backend
module in a "use" inside a string eval, which causes the syntax error.

If you do -MO=Concise,-debug, which is equivalent to

   use O qw(Concise -debug);

it works. This is shown in the B​::Concise synopsis​:

   perl -MO=Concise[,OPTIONS] foo.pl

Note there's a comma before OPTIONS, not an equal sign.

 - ilmari

--
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen

@p5pRT
Copy link
Author

p5pRT commented Mar 26, 2017

From @KES777

It seems that is possible through $^P variable. We should setup flag​:

x100
Provide informative "file" names for evals based on the place they were compiled.

but perlrun do not explain how to setup this variable through command line.

26.03.2017, 16​:16, "KES" <kes-kes@​yandex.ru>​:

ah, comma. Thank you.

is it possible/reasonable to improve error message here?

26.03.2017, 15​:54, "Dagfinn Ilmari Mannsåker via RT" <perlbug-followup@​perl.org>​:

 KES (via RT) <perlbug-followup@​perl.org> writes​:

  $ perl -MO=Concise=-debug -e '$xx ||= 3'
  syntax error at (eval 2) line 18, near "="
  BEGIN failed--compilation aborted.

 This has nothing to do with B​::Concise, but the fact that you are using
 the wrong syntax for -MO. -MO=Concise=-debug is equivalent to

     use O 'Concise=-debug';

 which O to try to use "B​::Concise=-debug" as the name of the backend
 module in a "use" inside a string eval, which causes the syntax error.

 If you do -MO=Concise,-debug, which is equivalent to

    use O qw(Concise -debug);

 it works. This is shown in the B​::Concise synopsis​:

    perl -MO=Concise[,OPTIONS] foo.pl

 Note there's a comma before OPTIONS, not an equal sign.

  - ilmari

 --
 "A disappointingly low fraction of the human race is,
  at any given time, on fire." - Stig Sandbeck Mathisen

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @tonycoz

On Sun, 26 Mar 2017 06​:26​:14 -0700, kes-kes@​yandex.ru wrote​:

It seems that is possible through $^P variable. We should setup flag​:

x100
Provide informative "file" names for evals based on the place they
were compiled.

but perlrun do not explain how to setup this variable through command
line.

I don't think that would be all that useful in this case, since the eval is in O.pm.

I tried propagating that the code came from the command-line by prepending​:

  #line 1 "<option text here>"

eg.

  #line 1 "-MO=Concise=-debug"

to the code generated for -[Mm] switch, and modifying O.pm to add a similar #line based on caller(), but the parser appears to ignore #line directives in PL_preambleav code.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @iabyn

On Sun, May 21, 2017 at 10​:16​:58PM -0700, Tony Cook via RT wrote​:

On Sun, 26 Mar 2017 06​:26​:14 -0700, kes-kes@​yandex.ru wrote​:

It seems that is possible through $^P variable. We should setup flag​:

x100
Provide informative "file" names for evals based on the place they
were compiled.

but perlrun do not explain how to setup this variable through command
line.

I don't think that would be all that useful in this case, since the eval is in O.pm.

I tried propagating that the code came from the command-line by prepending​:

#line 1 "<option text here>"

eg.

#line 1 "-MO=Concise=-debug"

to the code generated for -[Mm] switch, and modifying O.pm to add a
similar #line based on caller(), but the parser appears to ignore #line
directives in PL_preambleav code.

Although in general I kind of like the idea that warnings/dies from within
evals should show where the eval was compiled too. There's nothing more
frustrating than seeing an error "at (eval 13) line 7"

Maybe something like

  ... at (eval 13​: from foo.pl​:21) line 7

Not sure what it should for nested evals. Not bother, or show the chain​:

  ... at (eval 13​: from eval 15​:1 from foo.pl​:21) line 7

--
That he said that that that that is is is debatable, is debatable.

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From zefram@fysh.org

Dave Mitchell wrote​:

Not sure what it should for nested evals. Not bother, or show the chain​:

There are reasonable uses of eval that nest them to unbounded depth.
Currently unbounded nesting doesn't cause any problem, but storing the
chain for this purpose would change that. So you should at least store
only a bounded amount of the chain.

But showing any nesting in the way that you propose would break the
ability to use #line to properly imitate another location. You should
think about what changes you'd require of programs that do this.

-zefram

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @iabyn

On Mon, May 22, 2017 at 07​:25​:13PM +0100, Zefram wrote​:

Dave Mitchell wrote​:

Not sure what it should for nested evals. Not bother, or show the chain​:

There are reasonable uses of eval that nest them to unbounded depth.
Currently unbounded nesting doesn't cause any problem, but storing the
chain for this purpose would change that. So you should at least store
only a bounded amount of the chain.

I'm not envisioning storing anything extra. I would just work back
through the context stack as usual, but if the nearest enclosing sub is
an eval rather than a plain sub, then rather than just displaying
the 'eval N line 1' info from that context, it looks at that context's
saved PL_curcop, and if necessary works further up the context stack.

So this seems to be more an aesthetic rather than technical decision.

But showing any nesting in the way that you propose would break the
ability to use #line to properly imitate another location. You should
think about what changes you'd require of programs that do this.

If someone's changed the filename or line number, then we still use that.
The only change would be specifically that if perl would otherwise have
displayed the location as exactly (eval N line M) then it consults the
context stack and saved PL_curcop, to append "caller" info, recursing to a
depth TBA (quite possibly just 1).

--
My Dad used to say 'always fight fire with fire', which is probably why
he got thrown out of the fire brigade.

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @cpansprout

On Mon, 22 May 2017 12​:48​:44 -0700, davem wrote​:

On Mon, May 22, 2017 at 07​:25​:13PM +0100, Zefram wrote​:

Dave Mitchell wrote​:

Not sure what it should for nested evals. Not bother, or show the chain​:

There are reasonable uses of eval that nest them to unbounded depth.
Currently unbounded nesting doesn't cause any problem, but storing the
chain for this purpose would change that. So you should at least store
only a bounded amount of the chain.

I'm not envisioning storing anything extra. I would just work back
through the context stack as usual, but if the nearest enclosing sub is
an eval rather than a plain sub, then rather than just displaying
the 'eval N line 1' info from that context, it looks at that context's
saved PL_curcop, and if necessary works further up the context stack.

So this seems to be more an aesthetic rather than technical decision.

I don’t understand how what you are proposing differs significantly from what $^P|=0x100 already provides, unless you think the backtrace will actually help that much. I hope you are not proposing to make $^P|0x100 the default (because it is slower). But having a command-line option (other than -M'less=$^P|=0x100', which I actually use), might not be a bad thing.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

From @iabyn

On Mon, May 22, 2017 at 01​:53​:43PM -0700, Father Chrysostomos via RT wrote​:

I don’t understand how what you are proposing differs significantly from
what $^P|=0x100 already provides, unless you think the backtrace will
actually help that much.

Probably because I didn't understand what $^P does. The difference
in what I was proposing was that the location would be determined only
when required​: i.e. rather than at the start of every eval setting
CopFILE to "(eval 1 )[foo.pl​:1]", set it to "(eval 1 )" as before,
and only deduce the extra "foo.pl" info when printing a location in a
warn/die etc.

But if bulk88's deduping-CopFILE work gets finished and merged, then
the cost of having a longer CopFILE string would only be once per eval
rather than once per cop, so the extra cost would probably vanish.

I hope you are not proposing to make $^P|0x100
the default (because it is slower).

Well, making something like that the default (but only if its not slow).

--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
  -- Bill Royston

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @cpansprout

On Mon, 22 May 2017 23​:38​:52 -0700, davem wrote​:

On Mon, May 22, 2017 at 01​:53​:43PM -0700, Father Chrysostomos via RT wrote​:

I don’t understand how what you are proposing differs significantly from
what $^P|=0x100 already provides, unless you think the backtrace will
actually help that much.

Probably because I didn't understand what $^P does. The difference
in what I was proposing was that the location would be determined only
when required​: i.e. rather than at the start of every eval setting
CopFILE to "(eval 1 )[foo.pl​:1]", set it to "(eval 1 )" as before,
and only deduce the extra "foo.pl" info when printing a location in a
warn/die etc.

But if bulk88's deduping-CopFILE work gets finished and merged, then
the cost of having a longer CopFILE string would only be once per eval
rather than once per cop, so the extra cost would probably vanish.

I hope you are not proposing to make $^P|0x100
the default (because it is slower).

Well, making something like that the default (but only if its not slow).

You do realize, don’t you, that it won’t solve the original problem in the ticket? The syntax error was in -M code, not in an eval (unless it is implemented as an eval; I don’t remember). I once had a patch (probably still in a branch) that added ‘in preamble’ to the message if the line number was 0, precisely to solve this kind of problem, but it caused other problems, in that perl -h would add ‘in preamble’ to its output. I never got around to finishing it.

--

Father Chrysostomos

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

2 participants