Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.96k stars 556 forks source link

BBC: Blead Breaks Regexp::Grammars #19518

Open cjg-cguevara opened 2 years ago

cjg-cguevara commented 2 years ago

This is a bug report for perl from "Carlos Guevara" carlos@carlosguevara.com, generated with the help of perlbug 1.42 running under perl 5.35.10.


[Please describe your issue here]

BBC: Blead Breaks Regexp::Grammars

Please see http://matrix.cpantesters.org/?dist=Regexp::Grammars

[Please do not change anything below this line]


Flags: category=core severity=low

Site configuration information for perl 5.35.10:

Configured by cpan at Tue Mar 8 09:26:05 EST 2022.

Summary of my perl5 (revision 5 version 35 subversion 10) configuration: Commit id: f70b3f77e0c82e8e1b599de1542ef342631cb4f5 Platform: osname=openbsd osvers=7.0 archname=OpenBSD.amd64-openbsd uname='openbsd cjg-openbsd7 7.0 generic#5 amd64 ' config_args='-des -Dprefix=~/bin/perl-blead -Dscriptdir=~/bin/perl-blead/bin -Dusedevel -Duse64bitall' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define Compiler: cc='cc' ccflags ='-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' optimize='-O2' cppflags='-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='OpenBSD Clang 11.1.0' 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 ='-Wl,-E -fstack-protector-strong -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lpthread -lm -lutil -lc perllibs=-lpthread -lm -lutil -lc libc=/usr/lib/libc.so.96.1 so=so useshrplib=false libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags=' ' cccdlflags='-DPIC -fPIC ' lddlflags='-shared -fPIC -L/usr/local/lib -fstack-protector-strong'


@INC for perl 5.35.10: /home/cpan/bin/perl-blead/lib/site_perl/5.35.10/OpenBSD.amd64-openbsd /home/cpan/bin/perl-blead/lib/site_perl/5.35.10 /home/cpan/bin/perl-blead/lib/5.35.10/OpenBSD.amd64-openbsd /home/cpan/bin/perl-blead/lib/5.35.10


Environment for perl 5.35.10: HOME=/home/cpan LANG (unset) LANGUAGE (unset) LC_ALL=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/cpan/bin/perl-blead/bin:/home/cpan/bin:/home/cpan/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games PERL_BADLANG (unset) SHELL=/usr/local/bin/bash

haarg commented 2 years ago

This is the same as #19517. Opening a reference to undef and not writing to it is expected by the test to leave the variable as undef.

khwilliamson commented 2 years ago

Is this now closable?

hvds commented 2 years ago

Is this now closable?

My assumption is no: the intention is apparently to reintroduce the reverted change early in the 5.37 cycle, so this and the related BBC issues will then become relevant again. However if PSC judges that this and the other modules are simply over-testing things that have never been defined by perl core, we could probably close them all with SendToCPAN.

I did create an issue for this on the module at https://rt.cpan.org/Ticket/Display.html?id=141815, sorry I forgot to mention that here.

jkeenan commented 2 years ago

Is this now closable?

My assumption is no: the intention is apparently to reintroduce the reverted change early in the 5.37 cycle, so this and the related BBC issues will then become relevant again. However if PSC judges that this and the other modules are simply over-testing things that have never been defined by perl core, we could probably close them all with SendToCPAN.

I did create an issue for this on the module at https://rt.cpan.org/Ticket/Display.html?id=141815, sorry I forgot to mention that here.

@hvds, the upstream maintainer has marked your ticket Resolved. What then do we do next for this ticket?

hvds commented 2 years ago

@hvds, the upstream maintainer has marked your ticket Resolved. What then do we do next for this ticket?

Not sure: maintainer has a fix, but it is not yet released; the patch that caused the problem was reverted for 5.36, and has not yet been reapplied. However the intention was to reapply it, and at that point this module will fail until the fix is released.

I think first step is to decide if the patch is going to be reapplied, and if so to apply it now.