let B know about new op_code_list field

regmatch(): avoid 'may be used uninitialized' msg

Hoist a NULL assignment into a wider scope than is strictly necessary,
in order to avoid a spurious compiler warning.

propagate /msix and (?msix) etc flags into (??{})

In  /.........(??{ some_string_value; }).../flags
and /(?flags).(??{ some_string_value; }).../,

use flags when compiling the inner /some_string_value/ pattern.

Achieve this by storing the compile-time modifier flags in the
(apparently) unused 'flags' field of the EVAL node in the (??{})
case.

test that code within /(?{})/ etc is optimised

add tests for (?{ return foo })

All types of code blocks make use of the return value from the code
block. Check they all work, with and without an explicit 'return'.

un-TODO recursive split test

This test has been disabled for ages. It *should* work now, but I
cauldn't reproduce the failure in older perls, so I don't know for sure.

Also, the test appeared in two files due to the historical splitting of
pat.t into multiple test files. Remove the duplicate.

add test for /(??{exit})/

avoid 'unescaped left brace' warnings

Avoid braces warning in regen_perly.pl

re-apply temporarily remove overload.t changes

re-apply commits done to lib/overload.t on the blead branch between
2012/03/31 and 2012/06/04, which were removed to make rebasing the
re_eval branch easier.

add tests for $1 modified compiling code block

When compiling a run-time code-block, $1 etc should be protected against
any modifications that happen during compilation, e.g. via BEGIN

add tests that (?{}) etc called in scalar context

handle (??{}) returning an overloaded value

In this case, always pass the object to the regex compiler, which
knows how handle this.

(The diff looks more complex than it actually is: it just wraps
the whole (logical == 2) branch with an 'if (!SvAMAGIC(ret))'.)

handle weird/undef (?{}), (??{}) return value

All three code block variants: (?{}), (??{}), (?(?{}X|Y)),
make use of the return value of the block, either to set $^R, determine
truth, or to interpret as a pattern.  Evaluating this value may trigger
magic calls, uninitialized var warnings etc. Make sure that this
processing happens in the right environment; specifically, before we've
restored vars and paren indices, and we set PL_op temporarily to NULL so
that uninit var warnings don't try to look in the wrong place: neither the
outer op (eg OP_MATCH) nor the inner op (the last op of the code block:
currently happens to be OP_NULL, but that's a bug; will eventually be last
*real* op, e.g. padsv) are suitable for identifying where the warning came
from.

For the (??{}) case, if we can't extract a pre-compiled regex from it,
we force it to a PV, making a temp copy if necessary.

simply 'use bytes' handling of (??{})

make it slightly more readable without changing code logic.

further simplify (??{}) return code

This does two things. First, it conflates the RV and non-RV cases; i.e.

    if (ROK) {
        sv = RV(sv)
        if (REGEXP)  rx = sv;
        else if (PERL_MAGIC_qr) rx = mg_obj;
    }
    else {
        if (REGEXP)  rx = sv;
        else if (PERL_MAGIC_qr) rx = mg_obj;
    }

becomes

    if (ROK)
        sv = RV(sv)
    if (REGEXP)  rx = sv;
    else if (PERL_MAGIC_qr) rx = mg_obj;

Secondly, elmininate the intermediate rx var; it's only point in life is
to be assigned to re_sv, so just use re_sv throughout.

simplify the return code in (??{})

In the case where (??{...}) returns a non-reference with SMG,
there are two branches: if it has GMG too, we assert it hasn't got
PERL_MAGIC_qr, thus (intentionally) making redundant the following
sv_unmagic(ret, PERL_MAGIC_qr); otherwise we mg_find(ret, PERL_MAGIC_qr)
it.

This can all be reduced to a single mg_find() with no change in code
logic.

remove invalid assertion in (??{}) return code

propagate 'use re eval' into  return from (??{})

(??{}) returns a string which needs to be put through the regex compiler,
and which may also contain (?{...}) - so any 'use re eval' in scope needs
to be propagated into the inner environment. Achieve this by adding a new
private flag - PREGf_USE_RE_EVAL - to the regex to indicate the use is in
scope, and modify how the call to compile the inner pattern is done,
to allow the use state to be passed in.

save paren positions when running (?{}) code

Currently, all paren positions are saved before and after executing the
regops returned by (??{}); but not while the perl ops are being executed
beforehand. If the code happens to do a pattern match against the same
regex that's being currently run, then all iuts oparen positions will be
overwritten. So save them before entering the RUNOPS loop too.

fix refcount of rex attached to PL_reg_curpm

There were two mistakes; firstly, refcounts weren't consistently managed,
leading to premature frees when recursively calling a rex via (??{}).
It should be that PL_reg_curpm holds a single ref count for the rex it
points to, and that nothing else should hold a count.

Secondly, when making PL_reg_curpm point to a new rex, increment the new
*before* decrementing the old, in case they are both the same rex.

Both of these are now enforced by doing it within the SET_reg_curpm
(formerly SETREX) macro.

Tests will come in the next commit. I can't add them yet because they
also fail for other reasons (paren related).

perlreapi: fix documentation on last(close)?paren

lastparen was described as being last open paren; it's actually highest
close paren. Also make it clear these correspond to $+ and $^N

Remove redundant comment.

PL_reglastparen and PL_reglastcloseparen have been removed

remove some redundant code from CURLY rex ops

CURLY_B_*_fail all currently do:

    if (ST.paren && ST.count)
        rex->offs[ST.paren].end = -1;

but this is unnecessary. If B has just failed in the pattern /...(A)*B/,
then we will either adjust the amount of matched A, update rex->offs
(overwriting that -1) then call B again; or fail completely, do sayNO, and
backtrack to an op somewhere in the '...' before A. In this latter case,
the "somewhere else" op is the one responsible for unwinding the matched
parentheses, not us.

$+ and $^N not always correct on backtracking

Certain ops (TRIE, BRANCH, CURLYM, CURLY and related) didn't always
correctly restore or update lastcloseparen ($^N) - and sometimes lastparen
($+) - when backtracking, or doing a zero-length match (i.e. A* matching
zero times).

Fix this by saving lastcloseparen and lastparen in the relevant
regmatch_state union sub structs, then restoring as necessary.

reduce size of struct regmatch_state

Currently the trie struct is the largest sub-struct in the union;
reduce its size by 2 x 8 bytes (on a 64-bit system) by
    1) aligning a bool better
    2) eliminating ST.B, which can be trivially derived as
       ST.me + NEXT_OFF(ST.me)

(I'm going to partially spoil this by adding a new field in the next commit)

regcppush(): don't bother saving each paren number

regcppush() saves a contiguous range of slots in rex->offs[].
Currently it saves the index (paren number) along with each slot's data.
Since we know the top index (the saved PL_regsize) and the number of
elements, on restoring we can deduce each paren number without saving it.

set PL_reg_starttry correctly

PL_reg_starttry is only used for debugging, and S_regtry only set it
within DEBUG_EXECUTE_r; however, its value is also used within
DEBUG_STACK_r. So always set it when debugging, not just when
execute-debugging is enabled.

pp_match(): clarify intuit parens behaviour

There was some dodgy code, (flagged by dmq), that as well
as setting RX_LASTPAREN(rx),  RX_LASTCLOSEPAREN(rx) to zero,
also set RX_NPARENS(rx) to zero.

The actual logic is that if we reach that point, the pattern shouldn't
have any capturing parentheses, so instead of assigning zero to it, assert
that RX_NPARENS(rx) is zero.

S_regcppush/pop : don't save PL_reginput

currently, S_regcppush() pushes PL_reginput, then S_regcppop() pops its
value and returns it. However, all calls to S_regcppop() are currently in
void context, so nothing actually uses this value. So don't save it in the
first place.

improve -Mre=Debug,BUFFERS debugging

as well as showing save/restore of capture buffer contents,
also show buffer swaps and setting of individual elements
(at least for the common OPEN/CLOSE ops; I've skipped all the
harder CURLY stuff for now).

make regexp_paren_pair.start_tmp an offset

Currently the start_tmp field is a pointer into the string, whereas the
the start and end fields are offsets within that string. Make start_tmp
an offset too for consistency.

eliminate PL_reg_start_tmp, PL_reg_start_tmpl

PL_reg_start_tmp is a global array of temporary parentheses start
positions. An element is set when a '(' is first encountered,
while when a ')' is seen, the per-regex offs array is updated with the
start and end position: the end derived from the position where the ')'
was encountered, and the start position derived from PL_reg_start_tmp[n].
This allows us to differentiate between pending and fully-processed
captures.

Change it so that the tmp start value becomes a third field in the offs
array (.start_tmp), along with the existing .start and .end fields. This
makes the value now per regex rather than global. Although it uses a bit
more memory (the start_tmp values aren't needed after the match has
completed), it simplifies the code, and will make it easier to make a
(??{}) switch to the new regex without having to dump everything on the
save stack.

eliminate PL_reglast(close)?paren, PL_regoffs

eliminate the three vars
    PL_reglastcloseparen
    PL_reglastparen
    PL_regoffs
(which are actually aliases to PL_reg_state struct elements).

These three vars always point to the corresponding fields within the
currently executing regex; so just access those fields directly instead.

This makes switching between regexes with (??{}) simpler: just update
rex, and everything automatically references the new fields.

make Perl_... and my_re_op_compile sigs match

make perl build again on non-DEBUGGING builds

The PL_block_type debugging-only array is now used indeirectly in
ext/re/re-exec.c, which enables debugging even on non-debugging builds

make calling of /(?{}) code blocks correct

Formerly, it just updated PL_comppad, set PL_op to the first op of the
code block, and did CALLRUNOPS().

This had a lot of problems, e.g. depth of recursion, and not having
anything on the context stack for die/caller/next/goto etc to see, usually
leading to segfaults.

Make it so that it uses the MULTICALL API instead. This makes it push a
new stack and a CxSUB context stack frame; it also makes us share code
rather than rolling our own.

MULTICALL had to be extended in two ways to make this work; but these have
not yet been made part of the public API. First, it had to allow changing
of the current CV while leaving the current CxSUB frame in place, and
secondly it had to allow pushing a CV with a zero increment of CvDEPTH.
This latter is to handle direct literal blocks:

    /(?{...})/

which are compiled into the same CV as the surrounding scope; therefore we
need to push the same sub twice at the same depth (usually 1), i.e.

    $ ./perl -Dstv -e'sub f { /(?{$x})/ } f'
    ...
    (29912:-e:1) gvsv(main::x)

    STACK 0: MAIN
      CX 0: BLOCK  =>
      CX 1: SUB    =>           <=== the same sub ...
      retop=leave
    STACK 1: SORT
      CX 0: SUB    => UNDEF     <==== ... as this
      retop=(null)

(note that stack 1 is misidentified as SORT; this is a bug in MULTICALl
to be fixed later).

One has to be very careful with the save stack; /(?{})/ is designed
not to introduce a new scope, so that the effects of 'local' etc
accumulate across multiple block invocations (but get popped on
backtracking). This is why we couldn't just do a POP_MULTICALL/PUSH_MULTICALL
pair to change the current CV; the former would pop the save stack too.

Note that in the current implementation, after calling out to the first
code block, we leave the CxSUB and PL_comppad value in place, on the
assumption that it may be soon re-used, and only pop the CxSUB at the end
of S_regmatch(). However, when popping the savestack on backtracking, this
will restore PL_comppad to its original value; so when calling a new code
block with the same CV, we can't rely on PL_comppad still being correct.

Also, this means that outside of a code block call, the context stack and
PL_comppad are wrong; I can't think of anything within the regex code
that could be using these; but it if it turns out not to be the case,
then we'd have to change it so that after each code block call, we pop the
CxSUB off the stack and restore PL_comppad, but without popping the save
stack.

make is_bare_re bool. not int in re_op_compile

This flag pointer only stores truth, so make it a pointer to a bool rather
than to an int.

make OP_REGCRESET only for taint handling

The OP_REGCRESET op, which is sometimes prepended to the chain of ops
leading to OP_REGCOMP, currently serves two purposes; first to reset the
taint flag, and second to initialise PL_reginterp_cnt. The second purpose
is no longer needed, and the first has a bug, in that the op isn't
prepended when "use re 'eval'" is in scope.

Fix this by prepending the op solely when PL_tainting is in effect.
This also makes run-time regexes slightly more efficient in the
non-tainting case.

S_doeval(): saveop can never be null now

reindent S_doeval() following a code purge.

Only whitespace changes.

eliminate sv_compile_2op, sv_compile_2op_is_broken

These two functions, which have been a pimple on the face of perl for
far too long, are no longer needed, now that regex code blocks are
compiled in a sensible manner.

This also allows S_doeval() to be simplified, now that it is no longer
called from sv_compile_2op_is_broken().

eliminate OP_4tree type

This was an alias to OP, and formerly used by the old re_eval mechanism

rename and simplify PL_reg_eval_set

These days PL_reg_eval_set is actually aliased to
PL_reg_state.re_state_reg_eval_set.

Rename this field to re_state_eval_setup_done to make it clearer what it
represents; remove the PL_ backcompat macro; make it boolean;
and remove the two redundant macros RS_init and RS_set.

eliminate RExC_seen_evals and RExC_rx->seen_evals

these were used as part of the old "use re 'eval'" security
mechanism used by the now-eliminated PL_reginterp_cnt

eliminate PL_reginterp_cnt

This used to be the mechanism to determine whether "use re 'eval'" needed
to be in scope; but now that we make a clear distinction between literal
and runtime code blocks, it's no longer needed.

eliminate REG_SEEN_EVAL

This flag was set during pattern compilation if a (?{}) was encountered;
but is redundant now that we have pRExC_state->num_code_blocks.

add some more tests for PL_cv_has_eval

In particular, the use re 'eval' case wasn't tested for

pat_re_eval.t; test "use re 'eval'"

In this test file, firstly reduce all "use re 'eval'"s into the smallest
scope possible, and secondly, for each pattern which still requires this
in scope, also test that pattern without it in scope, but under eval, and
check that it dies.

Note that during the course of this branch, much that formerly needed
"use re "eval'" no longer does, which is the main reason we can dispense
with it so much in this commit.

bump re.pm version number

ensure regex evals report the right location

make sure that PL_curcop is set correctly on entry to a regex code block,
since (unlike a normal eval) there isn't always an initial OP_NEXTSTATE to
cause it to get set.  Otherwise, warning messages etc in the first
statement of the code block will appear to come from the wrong place.

Fix up runtime regex codeblocks.

The previous commits in this branch have brought literal code blocks
into the New World Order; now do the same for runtime blocks, i.e. those
needing "use re 'eval'".

The main user-visible changes from this commit are that:

* the code is now fully parsed, rather than needing balanced {}'s; i.e.
  this now works:
      my $code = q[  (?{ $a = '{' })  ];
      use re 'eval';
      /$code/

* warnings and errors are now reported as coming from "(eval NNN)" rather
 than "(re_eval NNN)" (although see the next commit for some fixups to
 that). Indeed, the string "re_eval" has been expunged from the source
 and documentation.

The big internal difference is that the sv_compile_2op() and
sv_compile_2op_is_broken() functions are no longer used, and will be
removed shorty.

It works by the regex compiler detecting the presence of run-time code
blocks, and feeding the whole pattern string back into the parser (where
the run-time blocks are now seen as compile-time), then extracting out
any compiled code blocks and adding them to the mix.

For example, in the following:

    $c = '(?{"runtime"})d';
    use re 'eval';
    /a(?{"literal"})\b'$c/

At the point the regex compiler is called, the perl parser will already
have compiled the literal code block and presented it to the regex engine.
The engine examines the pattern string, sees two '(?{', but only one
accounted for by the parser, and so constructs a short string to be
evalled: based on the pattern, but with literal code-blocks blanked out,
and \ and ' escaped. In the above example, the pattern string is

       a(?{"literal"})\b'(?{"runtime"})d

and we call eval_sv() with an SV containing the text

    qr'a              \\b\'(?{"runtime"})d'

The returned qr will contain the new code-block (and associated CV and
pad) which can be extracted and added to the list of compiled code blocks
of the original pattern.

Note that with this scheme, the requirement for "use re 'eval'" is easily
determined, and no longer requires all the pp_regcreset / PL_reginterp_cnt
machinery, which will be removed shortly.

Two subtleties of this scheme are that normally, \\ isn't collapsed into \
for literal regexes (unlike literal strings), and hints aren't inherited
when using eval_sv(). We get round both of these by adding and setting a
new flag, PL_reg_state.re_reparsing, which indicates that we are refeeding
a pattern into the perl parser.

pmruntime: make more use of Perl_re_op_compile

In the compile-time, non-code branch of pmruntime(), rather than
assembling the pattern string ourselves from the list of constant strings,
just pass the whole thing to Perl_re_op_compile() (or whatever eng->op_comp
is in scope) to assemble.

This has two benefits. First it avoids duplicating the concatenation code
(which already has to be present in Perl_re_op_compile), and it provides
more information to that function; in particular so that we can identify
a late-bound compile-time pattern, i.e. $foo =~ 'string-not-regex'.

free PL_regex_padav later

At the point where formerly it was freed, instead just free the individual
regexes and put &PL_sv_undef placeholders in the vacated PL_regex_padav
slots. Then free the actual array a lot later.

This is because at the point where PL_regex_padav used to be freed,
regexes can still hold pointers to CVs that have PMOPs that index into
PL_regex_padav; and while the array is being freed, it's state is
inconsistent (jn particular, sv_clear temporarily stores old indexes in
the top slot.)

This is a band-aid really; the proper solution is to get rid of
PL_regex_padav altogether and store the regexps in the pad.

improve skipping of regex [..] char class in toker

Recently S_scan_const() was enhanced to know when it was within a [...]
of a regex, so that it could ignore anything that looked like a code block
within it; i.e.
    [(?{...]
wasn't misinterpreted as the start of a (?{...})

However, the code was too simplistic, and didn't handle \[ and \] escapes
well enough; e.g. are these char classes or not?:

    \\\[abc\\\]
    \\\\[abc\\\\]

add PMf_USE_RE_EVAL flag

This isn't actually used in the pm_flags field of a PMOP, but is
used in the pm_flags arg of Perl_re_op_compile() to indicate
that this pattern should be compiled with "use re 'eval'" in scope

skip re_eval leak test under -Dmad

Under MAD, eval CVs are explicitly not freed, so the leak test
can't succeed.

mark a var as volatile to avoid longjmp warning

re-enable some threaded regex TODO tests

these were fixed via commit 6eea2b427407da46a602a3ca17cbe055f57c24c0

make _REGEXP_COMMON work under win32

There's an extra trailing semicolon which the win32 compiler doesn't like.

re/pat_re_eval.t: tidy some 'use re eval' tests

reduce the scope of 'use re eval' to the barest minimum;
I also discovered while doing this that one block had the use; ... no;
swapped, and this didn't die, so I've added a TODO test.

[perl #108780] Make /foo$qr/ work under ‘no overloading’

This commit redoes 37c07a4b2, which had to be reverted to allow the
re-eval work to be rebased onto blead.

It changes the code in re_op_compile (formerly in pp_regcomp) to use
the underlying REGEXP instead of the reference to it, when concatenat-
ing pieces to mark a larger regular expression.  This makes /foo$qr/
work even under ‘no overloading’.  It stopped working with commit
a75c6ed6b.

regcomp.c: Silence valgrind warning

This happens only in doing debug output.  Initialize these two debugging
variables

[ this commit was previously reverted to make rebasing easier; added back
now ]

undo temporarily reverted lib/overload.t tests"

some tests in lib/overload.t were temporarily removed earlier to ease
rebasing; add them back in now.

add tests for regex recompilation

The run-time regexp compilation (invoked via pp_regcomp()) has a mechanism
to skip the recompilation if the pattern text hasn't changed since the
last recompile. Astonishingly this mechanism isn't actually tested, so
here's a test file.

All the tests now pass, but this is due to the various recent fixes in
this branch. In particular, it never used to consider the UTF8ness of the
pattern string, or whether the pattern contained code blocks.

It works by checking the output of 'use re debug' (and -Dr if available)
to detect how many times the pattern was compiled.

This file then is also an indirect test of whether the correct debugging
output is generated, i.e. whether the regcomp.c or ext/re/re_comp.c
versions of functions are getting called.

force recompiling of regex where closures matter

There are some cases where on the second run of a run-time regex, the
text of the pattern hasn't changed, but we should still recompile to
ensure that closure behaviour is correct.

These cases are:

1) run-time code:

    my $code = '(??{$x})';
    for my $x (1..3) {
        $x =~ /$code/; # recompile to see fresh value of $x
    }

2) embedded regexes with code:

    for my $x (1..3) {
my $r = qr/(??{$x})/;
        "A$x" =~ /A$r/; # recompile to see new $r
    }

With this fix, all the TODO tests in re/pat_re_eval.t now pass. (Note that
a couple of those TODO tests were actually broken and are fixed in this
commit)

fix =/== typo in ext/re/t/regop.t

add op_comp field to regexp_engine API

Perl's internal function for compiling regexes that knows about code
blocks, Perl_re_op_compile, isn't part of the engine API. However, the
way that regcomp.c is dual-lifed as ext/re/re_comp.c with debugging
compiled in, means that Perl_re_op_compile is also compiled as
my_re_op_compile. These days days the mechanism to choose whether to call
the main functions or the debugging my_* functions when 'use re debug' is
in scope, is the re engine API jump table. Ergo, to ensure that
my_re_op_compile gets called appropriately, this method needs adding to
the jump table.

So, I've added it, but documented as 'for perl internal use only, set to
null in your engine'.

I've also updated current_re_engine() to always return a pointer to a jump
table, even if we're using the internal engine (formerly it returned
null). This then allows us to use the simple condition (eng->op_comp)
to determine whether the current engine supports code blocks.

re_op_compile(): merge the two 'eq old_re' checks

The code had two similar checks for whether the new pattern was the same
as the old (and so skip recompilation); the second was for after a longjmp
and upgrade to UTF8. By moving both checks to just after the
"if (jump_ret == 0)" block we should achieve code simplification without
any change in functionality

pat_re_eval.t: reduce scope of 'use re eval'.

My closure tests were initially covered by a blanket "use re 'eval'".
Now that no literal code blocks require this (especially where qr//s are
interpolated into another regex), only wrap the bits of test code that
really need it.

pat_re_eval.t: remove 'no warnings'

Now the the closure behaviour of code blocks within regexes is mostly
fixes, remove the

    no warnings qw(uninitialized closure);

that protected many of the closure tests.

This also showed up that one of my recent tests didn't realise
the whose test file is wrapped in a sub, so my test code destructor
looked like

    sub run_tests {
...
my $d;
sub DESTRUCTOR { $d++ }
...
    }

so fix that test to remove the closure warning.

add more tests for embedded qr// and code blocks

re_op_compile(): split flags into two arguments

There are two sets of regex-related flags; the RXf_* which
end up in the extflags field of a REGEXP, and the PMf_*, which
are in the op_pmflags field of a PMOP.

Since I added the PMf_HAS_CV and PMf_IS_QR flags, I've been conflating
these two meanings in the single flags arg to re_op_compile(), which meant
that some bits were being misinterpreted. The only test that was failing
was peek.t, but it may have quietly broken other things that simply
weren't tested for (for example PMf_HAS_CV and RXf_SPLIT share the same
value, so something with split qr/(?{...})/ might get messed up).

So, split this arg into two; one for the RXf* flags, and one for the PMf_*
flags.

The public regexp API continues to have only a single flags arg,
which should only be accepting RXf_* flags.

re_op_compile(): rename pm_flags to rx_flags

The orig_pm_flags argument and its modified copy, pm_flags, actually
contain bits related to REGEXPs (i.e. RXf_*) rather than PMOPs
(i.e.  PMf_*); although there is some overlap between the two sets of
bit flags.

Rename the variables to make this less unclear.
Ditto for re_compile().

add PMf_IS_QR flag

This indicates that a particular PMOP is in fact OP_QR. We should of
course be able to tell this from op_type, but the regex-compiling API
only gets passed op_flags.

This then allows us to fix a bug where we were deciding during compilation
whether to hang on to the code_blocks based on whether the PMOP was
PMf_HAS_CV rather than PMf_IS_QR; the latter implies the former, but not
the other way round.

fix scanning for code blocks

The toke code that scanned a pattern string to see if it looked like it
had any code blocks in it, used the wrong pointers. This then failed if
the pattern spread over multiple lines and buffers got reassigned.

tidy up the description of re_op_compile()

(also, it was incorrectly described as op_re_compile in a couple of places)

preserve code blocks in interpolated qr//s

This now works:

    { my $x = 1; $r = qr/(??{$x})/ }
    my $x = 2;
    print "ok\n" if "1" =~ /^$r$/;

When a qr// is interpolated into another pattern, the pattern is still
recompiled using the stringified qr, but now the pre-compiled code blocks
from the qr are reused rather than being re-compiled, so it behaves like a
closure.

Note that this makes some tests in regexp_qr_embed_thr.t fail, due to a
pre-existing threads bug, which can be summarised as:

    use threads;
    my $s = threads->new(sub { return sub { $::x = 1} })->join;
    $s->();
    print "\$::x=[$::x]\n";

which prints undef, not 1, since the *::x is cloned into the child thread,
then cloned back into the parent as part of the CV (linked from the pad)
being returned in the join. The cloning/join code isn't clever enough
to realise that the back-cloned *::x is the same as the original *::x, so
the main thread ends up with two copies.

This manifests itself in the re tests as

    my $re = threads->new( sub { qr/(?{$::x = 1 })/ })->join();

where, since the returned qr// is now a closure, it suffers from the same
glob duplication in the parent.

So I've disabled 4 re_tests tests under threads for now.

in re_op_compile(), keep code_blocks for qr//

code_blocks is a temporary list of start/end indices and pointers to DO
blocks, that is used during the regexp compilation. Change it so that in
the qr// case, this structure is preserved (attached to regexp_internal),
so that in a forthcoming commit it will be available for use when
interpolating a qr within another pattern.

pp_regcomp(): fix refcnt issue with qr_anoncv

Assigning to qr_anoncv was introduced a few commits ago, but
I forgot to increase the reference count

pm_runtime(): tidy some local vars

inline and delete the 'ext_eng' variable, as it's only used once;
and reduce the scope of 'eng'.

handle /$not_utf8(?{...})$utf8/

the bit of code that concats the args into a pattern and at the same time
notes the start and end indices of the text of the code blocks, got it
wrong if the pattern got upgraded half way through concatting. So work out
in advance whether the string is likely to be utf8.

inline S_get_pat_and_code_indices()

Now that that static function is only used in one place, get rid of it.

fix dumping of PMf_CODELIST_PRIVATE flag

"don't recompile pattern" check: account for UTF8

When recompiling a pattern (e.g. for $x (x,y) { /$x/ }),
it tests whether the new pattern string matches the old one, and if so
skips recompiling it. However, it doesn't take account of the UTF8ness of
the old and new patterns, so can falsely skip recompiling. Now fixed.

Also, there is a feature in re_op_compile() that may abort a pattern
compilation, upgrade the pattern to UTF8, then begin the compile again.
I've added a second check for whether the pattern matches the old pattern,
against the upgraded string. I can't see a way to test this, since its
just an optimisation.  Arguably I could add a BEGIN in an embedded code
block to see if it gets compiled twice, but soon I'm going to make it so
that embedded code blocks always get recompiled anyway.

re_op_compile: recalc code indexes on utf8 upgrade

As part of the compilation, we calculate the start and end positions
of the text of each literal code block within the pattern string.

The 'if pattern gets unexpected upgraded to UTF8, longjmp and restart
the compilation' mechanism, means that these indices can become invalid,
so if this happens, recalculate them. We do this by unrolling a call
to Perl_bytes_to_utf8(), which updates the indices at the same time that
it uopdtes the string.

Note that some of the new TODO test are actually passing, but this is for
the wrong reason. They're supposed to test for forced recompilation of
non-literal code blocks, even if the pattern string hasn't changed (which I
haven't implemented yet), but instead they're passing because the "don't
recomile if strings match" check isn't UTF8-aware. I'll fix this
(pre-existing) bug in the next commit.

in re_op_compile, change code_blocks[].end  offset

previously, code_blocks[].end pointed to the char *after* the
end of (?{...}); make it instead the last char, i.e. ')'.

This will make the code for the next commit slightly easier.

pp_regcomp(): fix casting issue from prev commit

Handle literal code blocks in runtime regexes

In the following types of regex:

      /$runtime(?{...})/
    qr/$runtime(?{...})/

make it so that the code block is compiled at the same time that the
surrounding code is compiled, then is incorporated, rather than
re-compiled, when the regex source is assembled and compiled at runtime.

This fixes a bunch of closure-related TODO tests.

Note that this still doesn't yet handle the cases where $runtime contains:
    $runtime = qr/...(?{...})/; # block will be stringified and recompiled
    $runtime = '(?{...})';      # block compiled the old way, with
                                  matching nesting of {} required

It also doesn't yet handle the case where the pattern getting compiled is
upgraded to utf8 and so is restarted.

Note that this is rather complex, because in something like

    $str =~ qr/$a(?{...})$b[1]/

there are four separate phases

* perl compile time; we also compile the code block at the same time,
  but within a separate anon CV (with a separate pad)

* at run time, we execute the code that generates the list of SVs
  (i.e. $a, $b[1] etc), but have to execute them within the context of the
  anon sub, since that's what they were compiled in; we then have to
  concat the arguments, while remembering which were literal code blocks;

* then qr// clones the compiled regex, and clones the anon CV at the same
  time;

* finally, the pattern is executed.

Through all this we have to ensure that the code blocks and associated
anon CV and pad get preserved and incorporated into the right places
for eventual use.

The changes in this commit build upon the work in the previous few
commits, and work by:

* at (perl) compile time, in pmruntime(), the anon CV (if any) associated
  with a qr//, as well as being referred to by the op_targ of the
  anoncode op, is also made the targ of the regcomp op;

* at pattern assembly and compile time,
    * Perl_re_op_compile() takes the list of SVs gathered by pp_regcomp(),
      along with the op tree (from op_code_list) that was used to generate
      those SVs (as well as containing the individual DO blocks), and
      concatenates them to get a final pattern source string, while
      noting the start and end positions of any literal (?{..})'s,
      and which block they must correspond to.

    * after compilation, pp_regcomp() then uses op_targ to locate
      the anon CV and store a pointer to it in the regex.

qr// instantiation and execution work unchanged.

re_op_compile(): rejig code-block handling code

In the code that keeps track of the start and end positions of each
code block, i.e. (?{....}), refactor it:

Rather than an array of STRLENs, with two slots to mark start and
positions, turn it into an array of structs; each holding the start and end
position, plus a pointer to the code block op. This will make it easier
when we shortly allow literal code from run-time patterns too.

Also rename some of the variables accordingly.

re_op_compile(): refactor some code

The 'scan the op tree looking for DO blocks' code will need to
be used in both the 'list of SV' and 'OP tree' cases, so hoist the code
up a level

remove target from REGCOMP op

after the previous commit, the target is no longer needed;
so don't allocate it.

Move bulk of pp_regcomp() into re_op_compile()

When called, pp_regcomp() is presented with a list of SVs on the stack.
Previously, it would perform (amongst other things):
  * overloading those SVs;
  * concatenating them;
  * detection of bare /$qr/;
  * detection of unchanged pattern;
optionally followed by a call to the built-in or an external regexp
compiler.

Since we want to avoid premature concatenation (so that we can handle
/$runtime(?{...})/), move all these activities from pp_regcomp() into
re_op_compile().

This makes re_op_compile() a bit cumbersome, with a large arg list,
but I haven't found any way of only moving only a subset of the above.

Note that a side-effect of this is that qr-overloading now works for all
regex compilations, not just those reached via pp_regcomp(); in particular
this now invokes the qr method rather than the "" method if available:
/(??{ $overloaded_object })/

add PMf_CODELIST_PRIVATE flag

This indicates that the op_code_list field in a PMOP is "private";
that is, it points to a list of DO blocks that we don't own, and
shouldn't free, and whose pad may not match ours.

This will allow us to use the op_code_list field in the runtime case of
literal code, e.g. /$runtime(?{...})/ and qr/$runtime(?{...})/. Here, at
compile-time, we need to make the pre-compiled (?{..}) blocks available to
pp_regcomp, but the list containing those blocks is also the list that is
executed in the lead-up to executing pp_regcomp (while skipping the DO
blocks), so the code is already embedded, and doesn't need freeing.
Furthermore, in the qr// case, the code blocks are actually within a
different sub (an anon one) than the PMOP, so the pads won't match.

remove private flag 1 from OP_REGCOMP

When an OP_REGCOMP is hand-rolled, the op_private flags field is
set to 1. This has been so since 1993, but it is undocumented and appears
completely unused. So remove it.

Fix =~ $str_overloaded (5.10 regression)

[ DAPM: I just cherry-picked the tests from this commit, since my own
  changes have already fixed this bug. FC's two commits:
      15d9c083b08647e489d279a1059b4f14a3df187b
      3e1022372a8200bc4c7354e0f588c7f71584a888
  were unrolled at the start of this branch since they clashed with my own
  stuff; this commit is re-adding the bits of those commits that are
  still needed: i.e. just the tests.
]

In 5.8.x, this code:

  use overload '""'=>sub { warn "stringify"; --$| ? "gonzo" : chr 256 };
  my $obj = bless\do{my $x};
  warn "$obj";
  print "match\n" if chr(256) =~ $obj;

prints

  stringify at - line 1.
  gonzo at - line 3.
  stringify at - line 1.
  match

which is to be expected.

In 5.10+, the stringification happens one extra time, causing a failed match:

  stringify at - line 1.
  gonzo at - line 3.
  stringify at - line 1.
  stringify at - line 1.

This logic in pp_regcomp is faulty:

    if (DO_UTF8(tmpstr)) {
assert (SvUTF8(tmpstr));
    } else if (SvUTF8(tmpstr)) {
... copy under ‘use bytes’...
    }
    else if (SvAMAGIC(tmpstr)) {
/* make a copy to avoid extra stringifies */
tmpstr = newSVpvn_flags(t, len, SVs_TEMP | SvUTF8(tmpstr));
    }

The SvAMAGIC check never happens when the UTF8 flag is on.

add volatile decl to fix previous commit

The previous commit changed the nature of the exp variable in
Perl_re_op_compile(), so it needs to be marked with VOL to work around
setjmp.

PATCH: [perl #101940]: BBC Tk

This commit that turned up this bug turns out merely exposes an
underlying problem that could be generated via other means.

regcomp.c was looking at the SvUTF8 flag on the input pattern before
doing an SvPV on it.  Generally the flag is considered not reliable
unless checked immediately after a SvPV.

I haven't been able to come up with a simple test case that reproduces
the bug.  I suspect that XS code is required to trigger it.

[ this is a re-application by davem of commit
  11951bcbfcaf4c260b0da0421e72fc80b4654f17 ]

regcomp.c: Use no_mg for 2nd fetch of pattern

The pattern could be tied, for example, and so only want to access it
once.  I couldn't come up with a test case that actually exercised this,
but I can think of future changes to regcomp that would.

[ this is a re-application by davem of commit
3e0b93e82af0f1a033bcdb918b413113f1d61cf0 ]

pp_regcomp: dopn't special-case n->1 arg folding

Currently, pp_regcomp() specially handles the case where the result of
concating all its args is a regexp. Change this so that this only occurs
if there is a single arg.

This means that if $a is an overloaded object whose concat op returns
a regexp, then /$a+/ no longer special-cases, and thus the returned regex
is now stringified and recompiled. This slight loss of efficiency in a
rare case is necessary to allow us to delay concating for as long as possible,