[MERGE] handle /(?{})/ with overload::constant qr
authorDavid Mitchell <davem@iabyn.com>
Fri, 12 Apr 2013 10:30:25 +0000 (11:30 +0100)
committerDavid Mitchell <davem@iabyn.com>
Fri, 12 Apr 2013 10:30:25 +0000 (11:30 +0100)
commite501306eca0fea1cc9fc53e2eb024ad37e85ce59
treec6456af41e20ed20741f24701229cb38bb4582d1
parent335e2ee52f38eaea7888c33d9c4f0d703130625e
parent4f3e2518850e12605980071a25c189c30710bcfd
[MERGE] handle /(?{})/ with overload::constant qr

The reworking of the re_eval implementation for 5.17.1 made the assumption
that constant strings within literal patterns were, um, constant.

It turns out this this is an invalid assumption, because

    overload::constant qr => { sub return bless [], 'Foo' }

can cause the constant bits of a pattern, like foo, bar in

    /foo(?{...})bar/

to get replaced with (for example) blessed objects: so the 'constant' SV
attached to an OP_CONST is actually a blessed object, that could itself be
overloaded with string or concat methods say, or could be a qr// object
etc.

The commits in this merge (hopefully) fix the various problems this
assumption caused: chiefly with qr// objects containing compiled (?{})
code that were getting re-stringified and thus failing unless in the
presence of use re 'eval' (and sometimes failing even in its presence).
Also, runtime patterns could trigger a recursive call to the overload
method, and eventually stack overflow and SEGV.

See [perl #116823].