Producing a default value from a do/try/catch block combination fails

[rage311]

Description

Even when following the exact code from the 5.34 perlsyn docs regarding producing a default value with a try/catch block wrapped in a "do" block, the code fails to produce the value.

Steps to Reproduce

#!/usr/bin/env perl

use 5.034;
use feature 'try';
no warnings 'experimental::try';

my $result = do {
  try {
    1 / 0;
  } catch ($e) {
    warn "Error: $e";
    1;
  }
};

say "'$result'";

Expected behavior
It outputs:

Error: Illegal division by zero at try_catch.pl line 9.
''

It should output:

Error: Illegal division by zero at try_catch.pl line 9.
'1'

EDIT: If you remove/comment the warn line, it works as expected.

Perl configuration

Summary of my perl5 (revision 5 version 34 subversion 0) configuration:
   
  Platform:
    osname=linux
    osvers=5.11.19-1-manjaro
    archname=x86_64-linux
    uname='linux x1n-manjaro 5.11.19-1-manjaro #1 smp preempt fri may 7 17:34:25 utc 2021 x86_64 gnulinux '
    config_args='-de -Dprefix=/home/user/perl5/perlbrew/perls/perl-5.34.0 -Aeval:scriptdir=/home/user/perl5/perlbrew/perls/perl-5.34.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
  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='10.2.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 =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.33.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.33'
  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'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under linux
  Compiled at Jun  2 2021 12:03:01
  %ENV:
    PERLBREW_HOME="/home/user/.perlbrew"
    PERLBREW_MANPATH="/home/user/perl5/perlbrew/perls/perl-5.34.0/man"
    PERLBREW_PATH="/home/user/perl5/perlbrew/bin:/home/user/perl5/perlbrew/perls/perl-5.34.0/bin"
    PERLBREW_PERL="perl-5.34.0"
    PERLBREW_ROOT="/home/user/perl5/perlbrew"
    PERLBREW_SHELLRC_VERSION="0.91"
    PERLBREW_VERSION="0.91"
  @INC:
    /home/user/perl5/perlbrew/perls/perl-5.34.0/lib/site_perl/5.34.0/x86_64-linux
    /home/user/perl5/perlbrew/perls/perl-5.34.0/lib/site_perl/5.34.0
    /home/user/perl5/perlbrew/perls/perl-5.34.0/lib/5.34.0/x86_64-linux
    /home/user/perl5/perlbrew/perls/perl-5.34.0/lib/5.34.0

[briang]

There's also some discussion on reddit

[mjreed-wbd]

The extra statement doesn't have to be a warn; if there's more than one statement in the catch block at all, the result is always undef.

[leonerd]

Indeed; any statement is sufficient to upset it:

eval: use feature 'try'; my $ret = do { try { die "Oopsie" } catch($e) { "result" } }; "Ret was $ret"
try/catch is experimental at (IRC) line 1.
try/catch is experimental at (IRC) line 1.
Ret was result

eval: use feature 'try'; my $ret = do { try { die "Oopsie" } catch($e) { my $x = 123; "result" } }; "Ret was $ret"
try/catch is experimental at (IRC) line 1.
try/catch is experimental at (IRC) line 1.
Ret was 

I suspect this is op_scope not propagating the context correctly.

[choroba]

Also, inserting do inside doesn't fix it:

my $ret = do {
    try {
        die "Oopsie"
    } catch($e) {
        do {
            my $x = 123;
            "result"
        }
    }
};

[wolfsage]

The problem seems to be when block_end on an op_scope() when op_scope() returns a block wrapped with an ENTER/LEAVE pair:

  PERLY_PAREN_CLOSE mblock[catch]
                        {
                          $$ = newTRYCATCHOP(0,
                                 $try, $scalar, block_end($remember, op_scope($catch)));

The first op will be a LEAVE, block_end will call scalarseq() on it, which will do:

      if (type == OP_LINESEQ || type == OP_SCOPE ||
            type == OP_LEAVE || type == OP_LEAVETRY)
        {
            OP *kid, *sib;
            for (kid = cLISTOPo->op_first; kid; kid = sib) {
                if ((sib = OpSIBLING(kid))
                 && (  OpHAS_SIBLING(sib) || sib->op_type != OP_NULL
                    || (  sib->op_targ != OP_NEXTSTATE
                       && sib->op_targ != OP_DBSTATE  )))
                {
                    scalarvoid(kid);
                }
            }
            PL_curcop = &PL_compiling;
        }

Which puts the ENTER into void context, and we get no return. I'm not sure what the right fix is though.

If we do this, things seem to work:

-                                 $try, $scalar, block_end($remember, op_scope($catch)));
+                                $try, $scalar, block_end($remember, newUNOP(OP_NULL, 0, op_scope($catch))));

Is it right? shrug

[leonerd]

Indeed. According to B::Concise:

cz                      <|> catch(other->d0)[$e:1600,1604] sK ->d8
-                          <0> null s ->d0
d7                         <@> leave sKP ->d8
d0                            <0> enter v ->d1
d1                            <;> nextstate(main 1602 try.t:255) v:%,*,&,x*,x&,x$,$,fea=15 ->d2
d4                            <2> sassign vKS/2 ->d5
d2                               <$> const(IV 123) s ->d3
d3                               <0> padsv[$x:1602,1603] sRM*/LVINTRO ->d4
d5                            <;> nextstate(main 1603 try.t:255) v:%,*,&,x*,x&,x$,$,fea=15 ->d6
d6                            <$> const(PV "result") s ->d7

I wonder if this is actually a bug in S_scalarseq?

[leonerd]

This bugfix ought to be considered for 5.34.1. How do I record that fact?

[choroba]

Shouldn't there be a label for that? Or an issue linking to other issues?

[Grinnz]

Label added to the PR #18888