From @eserte

This is a bug report for perl from slaven@​rezic.de,
generated with the help of perlbug 1.41 running under perl 5.27.9.

Pcore-v0.56.5 cannot be built anymore with 5.27.8 and later. Until
5.27.6 building was possible​:
http​://fast-matrix.cpantesters.org/?dist=Pcore%200.56.5
(No results for 5.27.7 because deps (Type​::Tiny) cannot be built here)

Running Build.PL fails immediately. It can also be reproduced like this​:

$ perl5.27.8 -Ilib -MPcore -e1
BEGIN not safe after errors--compilation aborted at /home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-0/lib/Pcore/Core/Event.pm line 3.
Compilation failed in require at lib/Pcore.pm line 565.
Compilation failed in require at lib/Pcore.pm line 414.
BEGIN failed--compilation aborted.

Flags​:
  category=core
  severity=low

Site configuration information for perl 5.27.9​:

Configured by eserte at Tue Feb 6 19​:16​:51 CET 2018.

Summary of my perl5 (revision 5 version 27 subversion 9) configuration​:
  Commit id​: ef80cd9
  Platform​:
  osname=linux
  osvers=3.16.0-4-amd64
  archname=x86_64-linux
  uname='linux cabulja 3.16.0-4-amd64 #1 smp debian 3.16.51-3 (2017-12-13) x86_64 gnulinux '
  config_args='-D useshrplib=true -Dprefix=/opt/perl5.27.8-157-gef80cd9 -Dusemymalloc=n -D cc=ccache cc -D usedevel=define -Duse64bit -de'
  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='ccache 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 -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so
  so=so
  useshrplib=true
  libperl=libperl.so
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E -Wl,-rpath,/opt/perl5.27.8-157-gef80cd9/lib/5.27.9/x86_64-linux/CORE'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'

@​INC for perl 5.27.9​:
  /opt/perl5.27.8-157-gef80cd9/lib/site_perl/5.27.9/x86_64-linux
  /opt/perl5.27.8-157-gef80cd9/lib/site_perl/5.27.9
  /opt/perl5.27.8-157-gef80cd9/lib/5.27.9/x86_64-linux
  /opt/perl5.27.8-157-gef80cd9/lib/5.27.9

Environment for perl 5.27.9​:
  HOME=/home/eserte
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/usr/bin​:/bin​:/usr/local/sbin​:/usr/sbin​:/sbin​:/home/eserte/bin/linux-gnu​:/home/eserte/bin/sh​:/home/eserte/bin​:/home/eserte/bin/pistachio-perl/bin​:/usr/games​:/home/eserte/devel
  PERLDOC=-MPod​::Perldoc​::ToTextOverstrike
  PERL_BADLANG (unset)
  SHELL=/bin/zsh

From @jkeenan

On Fri, 16 Feb 2018 19​:46​:58 GMT, slaven@​rezic.de wrote​:

This is a bug report for perl from slaven@​rezic.de,
generated with the help of perlbug 1.41 running under perl 5.27.9.

-----------------------------------------------------------------
Pcore-v0.56.5 cannot be built anymore with 5.27.8 and later. Until
5.27.6 building was possible​:
http​://fast-matrix.cpantesters.org/?dist=Pcore%200.56.5
(No results for 5.27.7 because deps (Type​::Tiny) cannot be built here)

Yes, and Porting/bisect.pl failed accordingly.

Running Build.PL fails immediately. It can also be reproduced like
this​:

$ perl5.27.8 -Ilib -MPcore -e1
BEGIN not safe after errors--compilation aborted at
/home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-
0/lib/Pcore/Core/Event.pm line 3.
Compilation failed in require at lib/Pcore.pm line 565.
Compilation failed in require at lib/Pcore.pm line 414.
BEGIN failed--compilation aborted.

Confirmed. The code is quite complex; I hope the author can look into it.

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

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

From @iabyn

On Fri, Feb 16, 2018 at 02​:39​:53PM -0800, James E Keenan via RT wrote​:

On Fri, 16 Feb 2018 19​:46​:58 GMT, slaven@​rezic.de wrote​:

Running Build.PL fails immediately. It can also be reproduced like
this​:

$ perl5.27.8 -Ilib -MPcore -e1
BEGIN not safe after errors--compilation aborted at
/home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-
0/lib/Pcore/Core/Event.pm line 3.
Compilation failed in require at lib/Pcore.pm line 565.
Compilation failed in require at lib/Pcore.pm line 414.
BEGIN failed--compilation aborted.

Confirmed. The code is quite complex; I hope the author can look into it.

The proximate cause is the recent switch in order of a sub's signature and
attributes; so code like this​:

  sub resolve_sockaddr ( $node, $service, $proto, $family, $type, $cb )
  : prototype($$$$$$)
  {
  ...
  }

is now a syntax error. *But*, as mentioned in another recent ticket, also
tends to throw up lots of spurious warnings, as perl attempts to
continue parsing after an error.

In this case, the code has a $SIG{__WARN__} handler, which gets called
even though the parser is errored. The handler ends a up requiring another
module which contains a 'use Foo', which is converted into
  BEGIN { require Foo; Foo->import },
and since PL_parser->error_count is >0, after compiling the BEGIN sub,
perl throws the 'BEGIN not safe after errors' error seen above rather than
actually requiring Foo.

This can be demonstrated in the following​:

  $ cat /tmp/lib/Foo.pm
  package Foo;
  use Bar 'baz';

  $ cat ~/tmp/p
  use warnings;

  BEGIN {
  $SIG{__WARN__} = sub {
  require Foo;
  };
  }

  $x =; # syntax error
  %h =~ /a/; # warning

  $ ./perl -I/tmp/lib ~/tmp/p
  syntax error at /home/davem/tmp/p line 11, near "=;"
  BEGIN not safe after errors--compilation aborted at /tmp/lib/Foo.pm line 2.
  Compilation failed in require at /home/davem/tmp/p line 7.
  $
 

So most directly the bug is in the module not adapting to the recent
change in syntax of the (experimental) signatures feature, but it also
links up with other recent threads on p5p related to

1) what do do about breakage associated with the recent signature change
2) what to do about emitting warnings after an error

and also ties in with an older discussion where I suggested that we abandon
parsing after any error - there are too many lexer and parser bugs
associated with trying to continue.

--
"You may not work around any technical limitations in the software"
  -- Windows Vista license

From @demerphq

On 20 Feb 2018 22​:56, "Dave Mitchell" <davem@​iabyn.com> wrote​:

On Fri, Feb 16, 2018 at 02​:39​:53PM -0800, James E Keenan via RT wrote​:

On Fri, 16 Feb 2018 19​:46​:58 GMT, slaven@​rezic.de wrote​:

Running Build.PL fails immediately. It can also be reproduced like
this​:

$ perl5.27.8 -Ilib -MPcore -e1
BEGIN not safe after errors--compilation aborted at
/home/cpansand/.cpan/build/2018021521/Pcore-v0.56.5-
0/lib/Pcore/Core/Event.pm line 3.
Compilation failed in require at lib/Pcore.pm line 565.
Compilation failed in require at lib/Pcore.pm line 414.
BEGIN failed--compilation aborted.

Confirmed. The code is quite complex; I hope the author can look into it.

The proximate cause is the recent switch in order of a sub's signature and
attributes; so code like this​:

  sub resolve_sockaddr ( $node, $service, $proto, $family, $type, $cb )
  : prototype($$$$$$)
  {
  ...
  }

is now a syntax error. *But*, as mentioned in another recent ticket, also
tends to throw up lots of spurious warnings, as perl attempts to
continue parsing after an error.

In this case, the code has a $SIG{__WARN__} handler, which gets called
even though the parser is errored. The handler ends a up requiring another
module which contains a 'use Foo', which is converted into
  BEGIN { require Foo; Foo->import },
and since PL_parser->error_count is >0, after compiling the BEGIN sub,
perl throws the 'BEGIN not safe after errors' error seen above rather than
actually requiring Foo.

This can be demonstrated in the following​:

  $ cat /tmp/lib/Foo.pm
  package Foo;
  use Bar 'baz';

  $ cat ~/tmp/p
  use warnings;

  BEGIN {
  $SIG{__WARN__} = sub {
  require Foo;
  };
  }

  $x =; # syntax error
  %h =~ /a/; # warning

  $ ./perl -I/tmp/lib ~/tmp/p
  syntax error at /home/davem/tmp/p line 11, near "=;"
  BEGIN not safe after errors--compilation aborted at /tmp/lib/Foo.pm
line 2.
  Compilation failed in require at /home/davem/tmp/p line 7.
  $

So most directly the bug is in the module not adapting to the recent
change in syntax of the (experimental) signatures feature, but it also
links up with other recent threads on p5p related to

1) what do do about breakage associated with the recent signature change
2) what to do about emitting warnings after an error

and also ties in with an older discussion where I suggested that we abandon
parsing after any error - there are too many lexer and parser bugs
associated with trying to continue

Is it possible we could exempt variable not declared errors from this
change?

The biggest value I see of continuing parsing and showing more errors is it
allows one to avoid playing whack-a-mole when dealing with such errors. You
can find and fix multiple variable uses and etc in one go. If this was
still possible then I don't think stopping on the first error of other
types would even be noticed....

Yved

From @iabyn

On Tue, Feb 20, 2018 at 05​:31​:49PM +0100, demerphq wrote​:

Is it possible we could exempt variable not declared errors from this
change?

The biggest value I see of continuing parsing and showing more errors is it
allows one to avoid playing whack-a-mole when dealing with such errors. You
can find and fix multiple variable uses and etc in one go. If this was
still possible then I don't think stopping on the first error of other
types would even be noticed....

Well, the rationale for for bailing out on the first error is that at that
point the lexer and parser are in an unknown and possibly inconsistent
state. Continuing to parse after that point to detect any further errors
is likely to trigger bugs. In fact fuzzing over recent years has shown
that there is a large supply of such bugs, and I doubt that we would ever
detect and fix them them all (perl's lexer being over 12K LoC).

So continuing is bad enough; continuing and possibly emitting further
warnings is even worse, as that could trigger a call to a $SIG{__WARN__}
and thus you're now actually executing code while the interpreter is in an
inconsistent state.

--
Fire extinguisher (n) a device for holding open fire doors.

From @demerphq

On 21 Feb 2018 17​:31, "Dave Mitchell" <davem@​iabyn.com> wrote​:

On Tue, Feb 20, 2018 at 05​:31​:49PM +0100, demerphq wrote​:

Is it possible we could exempt variable not declared errors from this
change?

The biggest value I see of continuing parsing and showing more errors is
it
allows one to avoid playing whack-a-mole when dealing with such errors.
You
can find and fix multiple variable uses and etc in one go. If this was
still possible then I don't think stopping on the first error of other
types would even be noticed....

Well, the rationale for for bailing out on the first error is that at that
point the lexer and parser are in an unknown and possibly inconsistent
state. Continuing to parse after that point to detect any further errors
is likely to trigger bugs. In fact fuzzing over recent years has shown
that there is a large supply of such bugs, and I doubt that we would ever
detect and fix them them all (perl's lexer being over 12K LoC).

So continuing is bad enough; continuing and possibly emitting further
warnings is even worse, as that could trigger a call to a $SIG{__WARN__}
and thus you're now actually executing code while the interpreter is in an
inconsistent state.

But none of that reasoning applies to undeclared lexicals. Such code would
compile fine without use strict.

So again, could we exempt that class of error from your proposed change? If
so I think most people would not even really notice something had changed.

Yves

From @iabyn

On Wed, Feb 21, 2018 at 11​:17​:04AM +0100, demerphq wrote​:

But none of that reasoning applies to undeclared lexicals. Such code would
compile fine without use strict.

So again, could we exempt that class of error from your proposed change? If
so I think most people would not even really notice something had changed.

So If I understand you right, we would stop immediately on first
encountering most errors, but some errors would be exempted from this and
we would continue parsing.

Exempted errors would be things that don't affect parsing state, like, as
you suggest, "Global symbol "$x" requires explicit package name", while
syntax errors and similar would immediately stop.

That seems plausible,

--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.

From @demerphq

On 21 Feb 2018 19​:50, "Dave Mitchell" <davem@​iabyn.com> wrote​:

On Wed, Feb 21, 2018 at 11​:17​:04AM +0100, demerphq wrote​:

But none of that reasoning applies to undeclared lexicals. Such code would
compile fine without use strict.

So again, could we exempt that class of error from your proposed change?
If
so I think most people would not even really notice something had changed.

So If I understand you right, we would stop immediately on first
encountering most errors, but some errors would be exempted from this and
we would continue parsing.

Yeah, I'm thinking anything that is only an error under 'use strict' would
be allowed to pile up, but anything that is an error regardless of 'use
strict' would stop further parsing.

Exempted errors would be things that don't affect parsing state, like, as
you suggest, "Global symbol "$x" requires explicit package name", while
syntax errors and similar would immediately stop.

Yep, exactly. I wouldn't necessarily go as far as 'doesnt affect parsing
state' as I imagine that might be a can of worms. Basing the rule on
whether something would be allowed without strictures would seem to provide
the value we try to provide with our current policy while being a simpler
policy.

That seems plausible,

If so then I imagine that your proposal will not be perceived as a patch
that takes away something useful but rather it will be perceived as
something that makes things outright better.

I believe many perl programmers "tune out" much of the error messages we
show as many of them are garbage caused by the current policy. The main
exception being that it can be very useful to see a list of the mistyped
vars in a script with one compilation run.

Yves

From @cpansprout

On Wed, 21 Feb 2018 01​:31​:28 -0800, davem wrote​:

On Tue, Feb 20, 2018 at 05​:31​:49PM +0100, demerphq wrote​:

Is it possible we could exempt variable not declared errors from this
change?

The biggest value I see of continuing parsing and showing more errors
is it
allows one to avoid playing whack-a-mole when dealing with such
errors. You
can find and fix multiple variable uses and etc in one go. If this
was
still possible then I don't think stopping on the first error of
other
types would even be noticed....

Well, the rationale for for bailing out on the first error is that at
that
point the lexer and parser are in an unknown and possibly inconsistent
state. Continuing to parse after that point to detect any further
errors
is likely to trigger bugs. In fact fuzzing over recent years has
shown
that there is a large supply of such bugs, and I doubt that we would
ever
detect and fix them them all (perl's lexer being over 12K LoC).

So continuing is bad enough; continuing and possibly emitting further
warnings is even worse, as that could trigger a call to a
$SIG{__WARN__}
and thus you're now actually executing code while the interpreter is
in an
inconsistent state.

$SIG{__WARN__} seems awfully similar to BEGIN blocks. It probably shouldn’t be allowed when PL_error_count is positive. (Instead, a error gets thrown.) But that might be too intrusive a change.

Though what Yves suggests is a plausible alternative.

--

Father Chrysostomos

The world moved on, Pcore was fixed, and while we might some time in the future make changes to how perl continues after an error it probably won't be through this ticket, so closing this.