[perl #52000] Warn/abort on attempted perl exit

[perl #52000] add perldiag entries for the new warnings

John Gardiner Myers is now a perl AUTHOR

[perl #52000] Warn/abort on attempted perl exit

[perl #114964] Correct 'ref' func POD to fix bad behavior around 'class matching'

mention reftype too

Brendan Byrd is now a perl AUTHOR

Correct 'ref' func POD to fix bad behavior around "class matching"

comments only, explain the different ONE_AT_A_TIME algos

Seeing 3 hash algos with the same name is confusing. If they are the same
name ("one at a time"), then why are there 3 different ones? What are the
differences (without reading the code)? What are the pros and cons of each?
INSTALL lists the ONE_AT_A_TIME algos as existing, but doesn't explain why
there are 3 of them. Patch with jkeenan suggestions.

perldelta for 2f222bbd/#119051 (\&$glob crashing)

[perl #119055] Make qq with no vars read-only

In commit 2484f8db I stopped constant folding from changing the read-
onliness of expressions like 1+2, which should return mutable values,
seeing that ${\1}+2 returns a mutable value.  (After all, constant
folding is supposed to be solely an optimisation, without changing
behaviour.)

This is accomplished by turning on the PADTMP flag, which tells opera-
tors like \ to copy the scalar.

I did not realise at the time that some qq strings like "hello\n" and
qq "foo" (but not just "foo") are implemented using constant folding.
The lexer outputs something like stringify("foo"), which is compiled
down to a stringify op with a constant ("foo") as its only child.

In this case we really do want qq"foo" to be treated as a single con-
stant.  That it is implemented using folding while "foo" is not is an
implementation detail we should hide.

So turn off the PADTMP flag when folding a stringify op.

Exempt clang from -Wunused-value when run as cc

We already have an exception for it when called as clang or clang-1.2.3,
but not when called as cc or anything else.  Mac OS X Mountain Lion
therefore ends up spitting out lots of warnings, as cc is a symlink
to clang.

[perl #119043] Exempt shared hash key consts from ro

Commit 19130678b4 stopped copy-on-write scalars from being exempt from
readonliness in ck_svconst (called for every OP_CONST).  That was for
the sake of consistency.

It turns out this breaks CPAN modules, so change it back, but only for
shared hash key scalars, not other COW scalars.

This is an historical artefact left over from when copy-on-write used
the read-only flag without the scalar actually being read-only.

[perl #119045] Make list constant mutable again

This broke CPAN.  Maybe we need to rethink this....

[perl #119051] Fix crash with \&$glob_copy

$ref = *Foo::nosub;
\&$ref;

The assignment creates a glob copy (coercible glob; one that down-
grades back to a simple scalar when assigned to).

\&$ref autovivifies a stub in that glob.  The CvGV pointer ends up
pointing to $ref, rather than *Foo::nosub.  $ref can easily cease
being a glob.  So crashes happen.

Stub autovivification used to stringify the glob, look it up again by
name, and then vivify the stub in the glob.

In commit 186a5ba82d584 I removed what seemed like a waste of CPU
cycles, but apparently it served some purpose.  The lookup caused CvGV
to point to *Foo::nosub, rather than $x.

This commit restores the stringfy-and-lookup if the glob is coercible
(SvFAKE).  It goes a little further and turns off the SvFAKE flag if
the glob just looked up is also FAKE.

It turns out this bug is old, and has been triggerable via glob copies
in stash elements for a long time.  186a5ba82d584 made it easier to
trigger the bug (so it is a regression from 5.16).

[MERGE] refactor pp_match(), pp_subst(), regexec()

Notionally the regexec engine has a well-defined API.
In practice, the caller of regexec() (typically pp_match() or pp_subst()),
is required to do a lot of set-up before calling regexec(), and some
post-processing afterwards; in particular to handle \G, to handle intuit,
and to set up $& correctly after an intuit-only match.

The series of commits in this branch refactors the code around these three
functions so that all the regex "knowledge"  is now contained within
regexec() rather than in the calling pp functions. At the same, time the
pp functions have been heavily cleaned up and simplified where possible.
This reduces the LOC in pp_match() from 305 to 186.

The most visible refactorisation changes are that:

* the call to intuit is now done from regexec() rather than from pp*;

* ditto the setting of $& on intuit-only matches;

* all the extra setup for \G is now in a single block of code in regexec(),
  rather than being distributed haphazardly across all 3 functions;

Along the way various things have been improved and bugs have been fixed:

* intuit-only matches had been inadvertently disabled when COW was enabled;
  this now fixed. (An intuit-only match is where intuit finding a suitable
  start position is sufficient to determine that the pattern has matched,
  e.g. a fixed string pattern /abc/ without captures);

* intuit-only substitutions had never been enabled; they are now;
  e.g /s/foo/bar/g

* formerly, intuit was skipped in the presence of anchored \G; this is no
  longer the case, so that something like "aaaa" =~ /\G.*xx/ now fails
  quickly due to the missing "xx";

* the COW code will try to reuse the COW copy SV on subsequent captures on
  the same regex and string, rather than freeing and reallocating.

* substitutions will no longer permit themselves to iterate "backwards",
  e.g. with s/.(?=.\G)/x/g;

* some obscure utf8 issues with s/// have been fixed;

* some bugs with \G fixed (and probably new ones added)

regexec(): add quick-fail test for anchored \G

under anchored \G, e.g. /ab\G/, we know that the start of the match must
be at (ganch-gofs); so fail quickly if that's off the beginning of the
string; or use it as the start point otherwise.

regexec: swap ganch setting and gofs offsetting

These two block of code are currently independent of each other, but swap
them round so that the calculated ganch value will be available for more
more clever gofs offset processing.

fix COW match capture optimisation

When an SV matches, a new SV is created which is a COW copy of the original
SV, and stored in prog->saved_copy, then prog->subbeg is set to point to
the (shared) PVX buffer.

Earlier in this branch I introduced an optimisation that skipped freeing
the old saved_copy and creating a new COW SV each time, if the old
saved_copy SV was already a shared copy of the SV being matched.

So far so good, except that I implemented it wrongly: if non-COW
matches (which malloc() subbeg) are interspersed with COW matches,
then the subbeg of the COW and the malloced subbeg get mixed up and
AddressSanitizer throws a wobbly.

The fix is simple: in the optimised branch, we still need to free subbeg
if RXp_MATCH_COPIED is true, then reassign it.

regexec(): avoid uninit use of var

clang pointed out that

    if (...)
goto phooey;
    oldsave = PL_savestack_ix;
    ...
  phooey:
    LEAVE_SCOPE(oldsave);

could use oldsave uninitialised. clang 1, dave 0.

fix /test_bootstrap.t under -DPERL_NO_COW

These tests check whether "require test.pl" inadvertently use $& etc.
They do that by doing a simple pattern match "Perl/ =~ /Perl/, then
checking that eval '$&' returns undef.

This has always been a dodgy thing o rely on. It turns out that under
5.18.0, whether eval '$&' was undef depended on whether the intuit-only-
match codepath was taken. So:

"Perl" =~ /Perl/;   eval '$&';   # intuit-only match: returned undef
"Perl" =~ /\w+\w*/; eval '$&';   # regexec() match: returned 'Perl'.

In this branch, the same code path is now used for both intuit() and
regexec() matches, so both return 'Perl'.

So, abandon this approach to the test, and instead read in tets.pl and
grep for the test '$&' etc.
Requires  minor fixup to test.pl to avoid a false positive.

fix build under -DPERL_NO_COW

An earlier commit in this branch fixed up capturing on intuit-only
matches.
However, the new code grabbed the buffer before setting offs[0].start,
offs[0].end.  Under old-style non-COW, it uses offs[0].start and end to
determine what subset to the buffer to capture. So set them first!

regexec(): access extflags directly

Some bits of code that had been moved from pp_match() etc into
regexec() still used the external API to access flags, i.e.

    RX_EXTFLAGS(rx)

Replace those uses with the more direct

    prog->extflags

for consistency with the rest of the code.

regexec(): tidy up ganch-setting code

Its a bit verbose with tons of debugging statements. Hard to see the wood
for the trees.

regexec(): merge the 2 RXf_GPOS_SEEN setup blocks

Change

    if (RXf_GPOS_SEEN) {
        ... adjust startpos ...
    }
    ...
    if (RXf_GPOS_SEEN) {
        ... calculate ganch ...
    }

to

    if (RXf_GPOS_SEEN) {
        ... adjust startpos ...
        ... calculate ganch ...
    }
    ...

Should contain no functional changes.

With this commit (building on many previous ones in this branch), all the
setup for \G is now in one place in regexec(), rather than scattered
across various places in pp_match(), regexec() etc.

regexec(): simplify RXf_ANCH_GPOS pos calc

There are two bits of code in regexec() that do special handling for
RXf_ANCH_GPOS:

First, after setting ganch from pos(), it does a couple of quick-fail
checks:
    fail if s > ganch
    fail if (ganch - gofs) < strbeg
at this point it also updates s to be ganch - gofs, although confusingly,
s in not subsequently used.

Second, when about to call regtry, it calculates a new  start value
(ignoring the old one, s):

    tmps_s = ganch - gofs;

then checks:
    fail if tmp_s < strbeg

As can be seen, these two sets of tests essentially partially duplicate
each other.

This commit moves all the work to the second block of code, which
simplifies things, and makes the first block of code purely about
calculating ganch.

Note that the new condition added by this commit in the second block,

    fail if s > tmp_s (i.e if s > (ganch - gofs))

subsumes both previous conditions, since
a) it is stronger than s > ganch
b) s will be >= strbeg, so tmp_s >= strbeg

regexec(): use regtry(&s) not regtry(&startpos)

regexec() has several cases such as anchored, floating etc, and for each
of these it will call regtry() one or more times to match at likely
starting positions. In all cases but one, it calls regtry(&s), where
s is the current start position that moves as we try new positions. In
the one final case it uses startpos instead, which is supposed to be static.
The actual code looks like:

    if (s == startpos && regtry(&startpos))

which might seem harmless, but under things like (*COMMIT), regtry can
update the pointer value (which is why its address is taken). So in this
(obscure) case, the wrong pointer gets updated.

s/.(?=.\G)/X/g: refuse to go backwards

On something like:

    $_ = "123456789";
    pos = 6;
    s/.(?=.\G)/X/g;

each iteration could in theory start with pos one character to the left
of the previous position, and with the substitution replacing bits that
it has already replaced.  Since that way madness lies, ban any attempt by
s/// to substitute to the left of a previous position.

To implement this, add a new flag to regexec(), REXEC_FAIL_ON_UNDERFLOW.
This tells regexec() to return failure even if the match itself succeeded,
but where the start of $& is before the passed stringarg point.

This change caused one existing test to fail (which was added about a year
ago):

    $_="abcdef";
    s/bc|(.)\G(.)/$1 ? "[$1-$2]" : "XX"/ge;
    print; # used to print "aXX[c-d][d-e][e-f]"; now prints "aXXdef"

I think that that test relies on ambiguous behaviour, and that my change
makes things saner.

Note that s/// with \G is generally very under-tested.

pp_subst: don't use REXEC_COPY_STR on 2nd match

pp_subst() sets the REXEC_COPY_STR flag on the first match. On the second
and subsequent matches, it doesn't set it in two out three of the branches
(including pp_susbstcont) where it calls CALLREGEXEC().
The one place where it *does* set it is a (harmless) mistake, since regexec
ignores REXEC_COPY_STR if REXEC_NOT_FIRST is set (which is it is, on all 3
brnanches).

So unset REXEC_COPY_STR in the third branch too, for consistency

pp_subst: combine 3 small elsif blocks into 1

and slightly reduce the scope of the temporary i var.

pp_subst: remove one use of 'm' local var

pp_subst: reduce scope of 'i' variable

it's just used a temporary var in a few blocks; declare it individually
in each block rather than being scoped to the whole function.

pp_subst: reduce scope of 'm' var

its mainly just a temporary local var; declare it individually within each
scope that makes use of it.

pp_subst: set/use s,m vars near where they're used

This should be just a cosmetic change; but basically change stuff like

    m = orig;
    s = foo();
    ... lots of lines not using s or m ...
    bar(m,s)
    ... more stuff using s ...

to

    ... lots of lines not using s or m ...
    s = foo();
    bar(orig,s)
    ... more stuff using s ...

This is part of few commits to generally clean up the scope and
comprehensibility of the vars within pp_subst

pp_subst: reduce scope of 'd' variable

It's just used as a temporary value in two branches;
so make it a local var in each of those branches.

pp_subst: cosmetic re-arrangement of vars

since 'orig' always points to the start of the string, while 's' varies,
change

    s = SvPV_nomg(...);
    ...other stuff using value of s ...
    orig = s
    ...

to

    orig = SvPV_nomg(...);
    ...other stuff using value of orig ...
    s = orig
    ...

No functional change, just reduces the cognitive load slightly

also adds some comments as to what force_on_match is about.

regexec(): fix ganch and till settings

Since startpos is now the \G-adjusted start position, use the real start
position instead (stringarg) when setting reginfo->till, and when setting
ganch in the non-pos case.

This stops this infinitely looping:

    $_ = "x"; pos = 1; @a = /x\G/g

regexec(): skip second intuit() call

A few commits ago, the call to intuit() done by the *callers* of
regexec() was moved into regexec() itself. Since regexec() could also call
intuit(), this temporarily led to the situation where intuit() was
harmlessly but inefficiently called twice. The last few commits have
removed the subtle differences between the conditions for each of the two
call points, so the second call to intuit() can now be removed.

A consequence of this is that we have to adjust the usage of the
'startpos' verses 's' variables; the original intent was that
startpos was constant, while s moved forward in the string after intuit
etc. This got a bit lost during the recent reorganisation, but is now
re-established. (startpos isn't quite constant: it will contain any
initial adjustment for \G.)

fix intuit_start() with \G

Intuit assumed that any anchor, including \G, anchored at BOS or after \n.
This obviously isn't the case for \G, so exclude RXf_ANCH_GPOS from the
RXf_ANCH branch.

This has never been spotted before, since intuit used to be skipped when
\G was present.

enable intuit under anchored \G, and fix a bug

Since 1999, regcomp has had approximately the following comment and code:

    /* XXXX Currently intuiting is not compatible with ANCH_GPOS.
       This should be changed ASAP!  */
    if ((r->check_substr || r->check_utf8) && !(r->extflags & RXf_ANCH_GPOS)) {
        r->extflags |= RXf_USE_INTUIT;
        ....

However, it appears that since that time, intuit has had (at least some)
support for achored \G added.
Note also that the RXf_USE_INTUIT flag (up until a few commits go)
was only used by *callers* of regexec() to decide whether to call intuit()
first; regexec() itself also internally calls intuit() on occasion, and in
those cases it directly checks just the check_substr and check_utf8 fields,
rather than the RXf_USE_INTUIT flag; so in those cases it's using intuit
even in the presence of anchored \G.

So, in the grand perl tradition of "make the change and see if anything
in the test suite breaks", that's what I've done for this commit
(i.e. removed the RXf_ANCH_GPOS check above).

So intuit is now normally called even in the presence of anchored \G.
This means that something like "aaaa" =~ /\G.*xx/ will now quickly fail in
intuit rather than more slowly failing in regmatch().

Note that I have no actual knowledge of whether intuit is *really*
anchored-\G-safe.

As it happens one thing in the test suite did break, and this was due to
the following code, added back in 1997:

    if (
        ....
        && !((RExC_seen & REG_SEEN_GPOS) || (r->extflags & RXf_ANCH_GPOS)))
   )
       r->extflags |= RXf_CHECK_ALL;

It was clearly meant to say that if either of those \G flags were present,
don't set the RXf_CHECK_ALL flag (which enables intuit-only matches).
But the '!' was set to cover the first condition only, rather than both.
Presumably this had never been spotted before due to skipping intuit under
anchored \G.

[Actually this commit broke some other stuff too, not covered by the test
suite.  See the next commit. Hooray for git rebase -i and history
re-writing!]

regexec_flags(): remove vestigial scream support

intuit has an arg (data) that used to be used for scream stuff, but which
is now unused. However, Perl_regexec_flags() still went to the trouble of
setting up that parameter when calling intuit. So stop doing that.

regexec_flags(): keep stringarg constant

stringarg is the arg passed to Perl_regexec_flags() to indicate where to
start matching. Currently the code adjusts this under \G, then copies it
to startpos, then later tinkers with startpos further.

Change it so that stringarg is never changed, and all the adjusting is to
startpos. Shouldn't make any logical difference, but makes the code
slightly cleaner and easier to understand (and doesn't require minend to
be adjusted any more).

regexec_flags(): use result of intuit_start()

When I moved the call to re_intuit_start() into Perl_regexec_flags()
a few commits earlier, I assigned the return value to the wrong variable,
so a subsequent match would still start at the beginning, not at the
intuited start point. This commit corrects that, by updating startpos
rather than stringarg.

pp_match: simplify pos()-getting code

The previous commit removed the \G handling from pp_match; most of what's
left in that code block is redundant code that just sets curpos under all
conditions. So tidy it up.

regexec: handle \G ourself, rather than in callers

Normally a /g match starts its processing at the previous pos() (or at
char 0 if pos is not set); however in the case of something like /abc\G/
we actually need to start 3 characters before pos. This has been handled
by the *callers* of regexec() subtracting prog->gofs from the stringarg
arg before calling it, or by setting stringarg to strbeg for floating,
such as /\w+\G/.

This is clearly wrong: the callers of regexec() shouldn't need to worry
about the details of getting \G right: move this code into regexec()
itself.

(Note that although this commit passes all tests, it quite possibly isn't
logically correct. It will get fixed up further during the next few
commits)

fix 114884 positive GPOS lookbehind regex substitution failure

This also corrects a test added in 2c2969659ae1c534e7f3fac9e7a7d186defd9943 which was
arguably wrong. The details of \G are a bit fuzzy, and IMO its a little hard to say exactly
what is right, although it generally is clear what is wrong.

pp_match(): don't set REXEC_IGNOREPOS on 1st iter

Currently all core callers of regexec set both the
REXEC_IGNOREPOS and REXEC_NOT_FIRST flags, or neither, depending
on whether this is the first or subsequent iteration of a //g;
*except* for one place in pp_match(), where REXEC_IGNOREPOS is set
on the first iteration for the one specific case of /g with an anchored
\G.

Now AFAICT this makes no difference, because the starting position
as calculated by regexec() still comes to the same value of
(strbeg + pos -gofs), and the same value og ganch calculated.

Also in the commit that added this particular use of the flag to pp_match,
(0ef3e39ecdfec), removing the flag makes no difference to the passing or
not of the new test case.

So I don't understand what its purpose it, and its possibly a mistake.
Removing it now makes the code simpler for further clearup.

pp_match(): stop setting $-[0] before regexec()

It doesn't actually achieve anything.

pp_match: avoid setting $+[0]

This function sometimes set $+[0] to pos() before calling regexec().
This value isn't used by regexec(), and was really just a way of updating
the new start position for //g. Replace it with a local var instead.

pp_match(): eliminate unused t variable

and restrict usage of s variable

pp_match(): skip passing gpos arg to regexec()

In one specific case, pp_match() passes the value of pos() to regexec()
via the otherwise unused 'data' arg.

It turns out that pp_match() only passes this value when it exists and is
>= 0, while regexec() only uses it when there's no pos magic or pos() < 0.

So its never used as far as I can tell.

So, strip it for now.

add some basic floating /\G/ tests

Floating is when the \G is an unknown number of characters from the start
of the pattern, such as /a+\G/. Surprisingly, there were no tests for this
form.

Here are a few basic tests just to exercise the main code paths. More
comprehensive tests could do with being added at some point.

fix /.\G/ under threading

When a regex was being duped, it's (constant) gofs field wasn't being
copied, but rather was being set to zero. Skip this and lots of TODO tests
pass.

skip creating new capture COW SV if possible

Each time we do a match, we currently (where possible) make a COW copy of
the just-matched string. This involves creating a new SV that shares the
same PVX buffer with the string. In a repeated match like while (/.../g),
that means the each time round we free the old capture SV and create a new
one.

As as optimisation, skip the free/create if the old capture SV is already
a COW clone of the match string.

make Perl_reg_set_capture_string static

This function was introduced a few commits ago. Since it's now only
called from within regexec.c, make it static.

add intuit-only match to s///

pp_match() has an intuit-only match mode: if intuit_start() succeeds and
the regex is marked as only needing intuit (RXf_CHECK_ALL), then calling
regexec() is skipped, and just $& set and then returns.

The commit which originally added that feature to pp_match() also added a
comment to pp_subst() suggesting that the same thing could be done there.

This commit finally achieves that. It builds on the previous commit (which
moved this mechanism from pp_match() directly into regexec()), skipping
calling intuit_start() and directly calling regexec() with the
REXEC_CHECKED flag not set.

This appears to reduce the execution time of a simple substitution
like s/abc/def/ by a fifth.

move intuit call from pp_match() into regexec()

Currently the main part of pp_match() looks like:

    if (can_use_intuit) {
        if (!intuit_start())
            goto nope;
        if (can_match_based_only_on_intuit_result) {
            ... set up $&, $-[0] etc ...
            goto gotcha;
        }
    }
    if (!regexec(..., REXEC_CHECKED|r_flags))
        goto nope;

  gotcha:
    ...

This rather breaks the regex API encapulation. The caller of the regex
engine shouldn't have to worry about whether to call intuit() or
regexec(), and to know to set $& in the intuit-only case.

So, move all the intuit-calling and $& setting into regexec itself.
This is cleaner, and will also shortly allow us to enable intuit-only
matches in pp_subst() too. After this change, the code above looks like
(in its entirety):

    if (!regexec(..., r_flags))
        goto nope;

    ...

There, isn't that nicer?

make intuit_start() handle mixed utf8-ness

Fix a bug in intuit_start() that makes it fail when the utf8-ness of the
string and pattern differ. This was mostly masked, since pp_match() skips
calling intuit in this case (and has done since 2000, presumably as a
workaround for this issue, and possibly for other issues since fixed).
But pp_subst() didn't skip, so code like this would fail:

    $c = "\x{c0}";
    utf8::upgrade($c);
    print "ok\n" if $c =~ s/\xC0{1,2}$/\xC0/i;

Now that intuit is (hopefully) fixed, also remove the guard in pp_match().

pp_match(): fix UTF* match setting

A recent commit did RX_MATCH_UTF8_set() based on the utf8-ness of the
pattern rather than the match string. I didn't matter because in that
branch they were guaranteed to have the same value, but fix it anyway,
both for correctness sake, and because it it *will* matter shortly

pp_match(): intuit can handle refs these days

It looks like we no longer need to skip intuit-only matching when the
match is a ref or overloaded (e.g. $ref =~ /ARRAY/)

pp_match(): remove ret_no label

The nope: and ret_no: labels labelled the same point in the code.
Eliminate one of them.

pp_match(): combine intuit and regexec branches

There was some code that looked roughly like:

    if (can_match_on_intuit_only) {
        ....
        goto yup;
    }
    if (!regexec())
        goto ret_no;

  gotcha:
    A; B;
    if (simple)
        RETURNYES;
    X; Y;
    RETURN;

  yup:
    A;
    if (!simple)
        goto gotcha;
    B;
    RETURNYES

Refactor it to look like

    if (can_match_on_intuit_only) {
        ....
        goto gotcha;
    }
    if (!regexec())
        goto ret_no;

  gotcha:
    A; B;
    if (simple)
        RETURNYES;
    X; Y;
    RETURN;

As well as simplifying the code, it also avoids duplicating some work
(the 'A' above was done twice sometimes) - harmless but less efficient.

pp_match(): refactor intuit-only code

change

    if (intuit_only)
        goto yup:
    ...
  yup:
    A; B; X; Y;

to

    if (intuit_only)
        A; B;
        goto yup:
    ...
  yup:
    X; Y;

where A and B are intuit_only-specific steps while X and Y are done by the
regexec() branch too. This will shortly allow us to merge the two
branches.

pp_match(): minor refactor: consolidate RETPUSHYES

Make the code slightly simpler by doing an early RETPUSHYES after success
where possible.

pp_match(): factor out some common code

Some identical code is used in two separate branches to set pos()
after a successful match. Hoist the common code to above the branch.

re-enable intuit-only matches

The COW changes inadvertently disabled intuit-only matches.
These are where calling intuit_start() to find the starting point for a
match is enough to know that the whole pattern will match, and so you can
skip calling regexec() too. For example, fixed strings without captures
such as /abc/.

The COW breakage meant that regexec was always called, making something
like /abc/ abut 3 times slower.

This commit re-enables intuit-only matches.

However, it turns out that this opens up a can of worms.
Normally, recording the just-matched-against string so that things like $&
and captures work, is done within regexec(). When this is skipped,
pp_match has to do a similar thing itself. The code that does this (which
is in principle a copy of the code in regexec()) is a bit of a mess. Due
to a logic error, a big chunk of it has actually been dead code for 10+
years.  Its had lots of modifications (e.g. people have made the same
changes to regexec() and pp_match()), but since it never gets executed,
errors aren't detected. And the bits that are executed haven't completely
received all the COW and SAWAMERSAND updates that have happened recently.

The Best way to fix this is is to extract out the capture code in
regexec() into a separate function (which we did in the previous commit),
then throw away all the broken capture code in pp_match() and replace it
with a call to the new function (which this commit does).

One side effect of this commit is that as well as restoring intuit-only
behaviour for the patterns that used to pre-COW, it also enables this
behaviour for patterns which formerly didn't, namely where $& or //p are
seen.

This commit is the barest minimum necessary to fix this; subsequent
commits will clean and improve this.

add Perl_reg_set_capture_string() function

Cut and paste into a separate function, the block of code in
regexec_flags() that is responsible (on successful match) for setting
RX_SAVED_COPY, RX_SUBBEG etc, ready for use by capture vars like $1, $&.

Although this function is currently only called from one place, we will
shortly use it elsewhere too.

This should contain no functional changes.

perl5191delta: deep recursion warnings (07b2687d2/#118521)

[Merge] Constants, inlined subs, TARGs, ...

This branch fixes many inconsistencies in the way constants, inlinable
subroutines, and operator return values (TARGs) are handled.

• Constant folding no longer causes operators to return read-only sca-
  lars that would otherwise return mutable scalars (1+2, "thr"."ee").
• Modifying mutable scalars returned from operators no longer affects
  future return values (this affected the range operator).
• Subroutines like sub () {42} always return mutable scalars.
• Constants like 1 and "two" now always produce read-only scalars.
• Constants created by ‘use constant’ always return read-only scalars.
• Referencing an operator return value, or a constant under threads,
  no longer creates a new scalar, causing print \$_, \$_ to print two
  different addresses.

This list is not exhaustive.

Version number tweaks in tests and other cleanup

I didn’t have this constant stuff ready as soon as I expected.  I also
left a comment and a couple of ‘local $TODO’s lying around that don’t
need to be there.  As a bonus, correct a typo in constant.pm’s docu-
mentation.

pad.c apidocs: Clarify use of &PL_sv_no

specifically with regard to possible future changes.

Fix up IO::Compress tests

They were expecting \"abc" to return a constant value, but constant
folding no longer causes \ to return a read-only scalar.

Increase $XS::APItest::VERSION to 0.55

Stop op freeing from interfering with sub(){42} mutability

The problem is that when an OP_CONST is freed, it calls pad_swipe,
which clears the PADTMP flag when removing the SV from the pad.  Since
PADTMP no longer necessarily means ‘in a pad’, we shouldn’t turn
this flag off.

fresh_perl.t: Make the test for #3066 more explicit

This test was added to make sure that constants don’t become undefined
as a result of being shared between ops.

What was tested, though, was a side-effect, and not the actual bug
itself.

This behaviour has changed (sub(){42} now returns a mutable val-
ue), so this test needs to change, too.  It was only passing under
ithreads, and only as the result of another bug, which the next com-
mit will fix.

Make overloaded constants always read-only

They were not read-only if the constant handler returned a shared
hash key scalar.

This was brought up in bug #109744.

Don’t check IS_PADCONST in pad.c:pad_alloc

Since recent commits have given constants &PL_sv_no names, this check
is redundant, since any slots for constants will have been skipped
over by the sv != &PL_sv_undef check just above.

pad.c: Don’t copy shared hash key targets when cloning

When creating a new thread, don’t treat shared hash key targets as
constants.  (See the previous commit for explanation.)

This should cause no change in behaviour, because the new target will
not be in use, and its next use will immediately overwrite its value.
It just saves having to copy a string that will be overwritten.

Stop shared hash key TARGs from being shared

A CV has a list of pads containing a different pad for each recursion
level.  pad_push, which adds a new pad to the list, copies some items
from pad no. 1 but not others.  In particular op targets¹ are created
anew, but, under ithreads, constants² are not.  Historically, these
were distinguished from each other by flags on the value.  Any read-
only or shared hash key scalar was considered to be a constant, and
hence shared between pads.  The target returned by ref() is a shared
hash key scalar, so it was being shared between recursion levels.
Recent commits have made it possible to distinguish between constants
and targets based on the name.  Formerly, both were nameless pad
entries.  Now constants have zero-length names (PadnamePV(name) &&
!PadnameLEN(name)).  So we can use that to fix this bug.

¹ Many operators return the same scalar each time, for efficiency.
  This is stored in the pad, and is known as the target, or TARG.
² Constanst are stored in the pad under ithreads, instead of being
  attached directly to ops, as they are under non-threaded builds.

[perl #79908] Stop sub inlining from breaking closures

When a closure closes over a variable, it references the variable
itself, as opposed to taking a snapshot of its value.

This was broken by the constant optimisation added for
constant.pm’s sake:

{
    my $x;
    sub () { $x };  # takes a snapshot of the current value of $x
}

constant.pm no longer uses that mechanism, except on older perls, so
we can remove this hack, causing code like this this to start work-
ing again:

BEGIN{
    my $x = 5;
    *foo = sub(){$x};
    $x = 6
}
print foo; # now prints 6, not 5

Make sub(){42} return a mutable value

But only make it do so in lvalue context.  This will be just as fast
in true rvalue context.  In either case, it is still inlined.

This makes sub () { 42 } and sub () { return 42 } do the same thing.

It also means that sub () { '-'x75 } reverts back to returning a muta-
ble value, the way it did in 5.16.  From now on, tweaks to constant
folding will no longer affect the mutability of the return value of a
nullary function.

‘use constant’ is unaffected.  It still returns read-only values.

This was brought up in ticket #109744.

Tweak optree_constants.t for inlined list consts

Update constant.pm to reflect list inlinement

I also removed ‘some symbols may be redefined without generating a
warning’.  I know not to what it refers.  It has been there as long as
constant.pm has.  If a constant is clobbered by another constant with
the same value, there is no warning, as it is harmless.  That may be
to what it refers, but we don’t need a caveat for that.

Inline list constants

These are inlined the same way as 1..5.  We have two ops:

  rv2av
    |
    `-- const

The const op returns an AV, which is stored in the op tree, and then
rv2av flattens it.

constant.pm: Make list constants read-only

Here we take advantage of the array-ref-stash-elem mechanism added in
the previous commit, which causes the actual elements of the stored
array to be pushed on to the stack.

Allow stash elems to be array refs

These turn into CVs that return the contents of the array.  Future
commits will make constant.pm use these and also make them inlinable.

Even without inlining, these subs are faster, because they are XSUBs:

$ time ./perl -Ilib -e 'my @a=1..1000000; sub foo { @a } () = foo for 1..10'

real 0m3.725s
user 0m3.407s
sys 0m0.227s
$ time ./perl -Ilib -e 'my @a=1..1000000; BEGIN { $::{foo} = \@a } () = foo for 1..10'

real 0m2.153s
user 0m1.949s
sys 0m0.121s

Increase $constant::VERSION to 1.28

Stop constant.pm from (ab)using subs for scalars

under versions that support $::{foo} = \1.

This changes no behaviour.  Future commits will change the way
sub(){42} and sub(){$forty_two} work.  (The former will return a muta-
ble value; the latter will not be inlined at all.)

[perl #78194] Make re-evals copy PADTMPs

So that \$_ == \$_ will be true in "$foo$bar" =~ /(?{...})/.

Many ops return the same scalar each time, for efficiency; refgen (\)
knows about that and copies them, to hide the implementation detail,
but other constructs, such as regular expression code blocks in this
case, need to do the same thing.

[perl #78194] Make sort copy PADTMPs

Copy PADTMPs (op return values) when there is a sort block/sub that is
not optimised away and we are not sorting in place, so that \$a == \$a
will return true.

Many ops return the same scalar each time, for efficiency; refgen (\)
knows about that and copies them, to hide the implementation detail,
but other ops (sort in this case) need to do the same thing.

[perl #78194] Make x copy PADTMPs in lv cx

So that \(("$a")x2) will give two references to the same scalar, the
way that \(($a)x2) does.

[perl #78194] Make list slices copy PADTMPs in lv cx

So that slices that reference the same value multiple times (such as
(...)[1,1]) will exhibit referential identity (\(...)[1,1] will return
two references to the same scalar).

Stop folding of ops from changing mutability

If $a+$b produces a mutable value, then so should 1+2.

[perl #78194] Make foreach copy pad tmps

before aliasing them to $_.

This caused one to-do test in sub.t to pass, but the bug it is testing
for has not been fixed, so I added another one.  I didn’t remove the
to-do test that started passing, because it is still a good test to
have (the only test we have for interactions betwen foreach, shared
hash keys, and recursion).

Correct list.t descr in MANIFEST

We don’t use the term ‘array’ for lists any more.  Also, mention
slices, since list slices are tested here.

[perl #3105] Make 1..3 modification safe

This construct is optimised at compile time to an anonymous array with
an implicit @{} around it if both arguments are constant.  Modifying
elements of that array produces wrong results the next time the same
code is executed.

If we mark each element of the array as PADTMP, then it will be
treated like an operator’s return value (which it is) and get copied
as appropriate.

constant.t: Correct version

I didn’t have this done in time for 5.19.1.

[perl #78194] Make sub calls copy pad tmps

before aliasing them to elements of @_.

Increase $OptreeCheck::VERSION to 0.10

though I still don’t understand why it has a version at all.

[perl #78194] Make grep/map copy pad tmps

before aliasing them to $_.

And make sure the copies go back on the stack for grep, since modi-
fying $_ in the grep block or expression is supposed to modify the
item returned.