Handle /@a/ array expansion within regex engine
authorDavid Mitchell <davem@iabyn.com>
Wed, 17 Apr 2013 16:51:16 +0000 (17:51 +0100)
committerDavid Mitchell <davem@iabyn.com>
Sat, 20 Apr 2013 16:23:13 +0000 (17:23 +0100)
commit491453ba443e114f751f325a4734b3d07b897606
tree87b6bab51aef762b2ca41740bfdb3a5c2f3da024
parentaec899470a3eab4f34d5c0404678e42b6823085a
Handle /@a/ array expansion within regex engine

Previously /a@{b}c/ would be parsed as

    regcomp('a', join($", @b), 'c')

This means that the array was flattened and its contents stringified before
hitting the regex engine.

Change it so that it is parsed as

    regcomp('a', @b, 'c')

(but where the array isn't flattened, but rather just the AV itself is
pushed onto the stack, c.f. push @b, ....).

This means that the regex engine itself can process any qr// objects
within the array, and correctly extract out any previously-compiled
code blocks (thus preserving the correct closure behaviour). This is
an improvement on 5.16.x behaviour, and brings it into line with the
newish 5.17.x behaviour for *scalar* vars where they happen to hold
regex objects.

It also fixes a regression from 5.16.x, which meant that you suddenly
needed a 'use re eval' in scope if any of the elements of the array were
a qr// object with code blocks (RT #115004).

It also means that 'qr' overloading is now handled within interpolated
arrays as well as scalars:

    use overload 'qr' => sub { return  qr/a/ };
    my $o = bless [];
    my @a = ($o);
    "a" =~ /^$o$/; # always worked
    "a" =~ /^@a$/; # now works too
op.c
regcomp.c
t/re/overload.t
t/re/pat_re_eval.t
toke.c