Move Cwd and List-Util to folders named as per their CPAN distributions
Fix RT #120600: Variable length lookbehind is not variable

Inside of study_chunk() we have to guard against infinite
recursion with recursive subpatterns. The existing logic
sort of worked, but didn't address all cases properly.

  qr/
    (?<W>a)
    (?<BB>
      (?=(?&W))(?<=(?&W))
    )
    (?&BB)
  /x;

The pattern in the test would fail when the optimizer
was expanding (&BB). When it recursed, it creates a bitmap
for the recursion it performs, it then jumps back to
the BB node and then eventually does the first (&W) call.
At this point the bit for (&W) would be set in the bitmask.
When the recursion for the (&W) exited (fake exit through
the study frame logic) the bit was not /unset/. When the parser
then entered the (&W) again it was treated as a nested and
potentially infinite length pattern.

The fake-recursion in study-chunk made it little less obvious
what was going on in the debug output.

By reorganizing the code and adding logic to unset the bitmap
when exiting this bug was fixed. Unfortunately this also revealed
another little issue with patterns like this:

  qr/x|(?0)/
  qr/(x|(?1))/

which forced the creation of a new bitmask for each branch.
Effectively study_chunk treats each branch as an independent
pattern, so when we are expanding (?1) via the 'x' branch
we dont want that to prevent us from detecting the infinite recursion
in the (?1) branch. If you were to think of trips through study_chunk
as paths, and [] as recursive processing you would get something like:

  BRANCH 'x' END
  BRANCH (?0) [ 'x' END ]
  BRANCH (?0) [ (?0) [ 'x' END ] ]
  ...

When we want something like:

  BRANCH 'x' END
  BRANCH (?0) [ 'x' END ]
  BRANCH (?0) [ (?0) INFINITE_RECURSION ]

So when we deal with a branch we need to make a new recursion bitmask.
Remove unused var from APItest.xs

This was added at the same time as the containing function in 27fcb6ee.
It was probably due to copy and paste.
Module-CoreList on CPAN is 3.01
Skip dist/ExtUtils-Install/t/InstallWithMM.t when cross-compiling.

The toolchain is not installed on the target when cross-compiling.
So, this test must be skipped, see patch below.
(same problem as RT#119769 and RT#120398)

For: RT #120615
Get perl to build under STRESS_REALLOC once more

It had been broken since v5.17.6-144-ga3444cc.

That commit added, inter alia, this comment to scope.h:

+ * Of course, doing the size check *after* pushing means we must always
+ * ensure there are SS_MAXPUSH free slots on the savestack

But STRESS_REALLOC makes the initial savestack size just 1, and
SS_MAXPUSH is 4.  So ‘./miniperl -e0’ failed an assertion.
Extend STRESS_REALLOC to move the stack with every EXTEND

This allows us easily to catch cases where the stack could move to a
new memory address while code still holds pointers to the old loca-
tion.  Indeed, this causes test failures.
Remove redundant SPAGAIN & PUTBACK after PUSHSTACKi().

PUSHSTACKi() calls SWITCHSTACK(), which sets PL_stack_sp and sp like this:

    sp = PL_stack_sp = PL_stack_base + AvFILLp(t)

Hence after PUSHSTACKi() both are identical, so use of SPAGAIN or PUTBACK
to assign one to the other is redundant.

The use of SPAGAIN in encoding.xs and via.xs was added with commit
24f59afc531955e5 (April 2002) which added the use of PUSHSTACKi(). It feels
like cargo-cult.

The use of PUTBACK in Perl_amagic_call() predates the introduction of nested
stacks and PUSHSTACKi() in commit e336de0d01f30cc4 (April 1998). It dates from
perl 5.000, but it's not clear that it was ever needed, as the code in
question looked like this, and nothing could have moved the stack between
the dSP and PUTBACK:

    dSP;
    BINOP myop;
    SV* res;

    Zero(&myop, 1, BINOP);
    myop.op_last = (OP *) &myop;
    myop.op_next = Nullop;
    myop.op_flags = OPf_KNOW|OPf_STACKED;

    ENTER;
    SAVESPTR(op);
    op = (OP *) &myop;
    PUTBACK;

The PUTBACK and SPAGAIN in Perl_require_pv() were added by commit
d3acc0f7e5197310 (June 1998) which also added the PUSHSTACKi(). They have
both been redundant since they were added.
S_process_special_blocks() should use a new stack for BEGIN blocks.

This avoids the stack moving underneath anything that directly or indirectly
calls Perl_load_module().

[Committer’s note:

 This fixes bug #119993.

 Furthermore, under STRESS_REALLOC, t/io/layers.t was crashing like this:

 $ ./perl -Ilib -e ' open(UTF, "<:raw:encoding(utf8)", 'tmp75851B') or die $!; ref #blahblahblahblahblahblahblahblahblah'
 Segmentation fault: 11

 (The comment seems to be necessary to make it crash.)

 It was happening because open() was causing a module to be loaded
 while the arguments to open() were still on the stack.
]
Perl_load_module() no longer moves the current stack, so no need to save it.
No need to wrap calls to Perl_load_module() in ENTER/LEAVE

As of commit 53a7735b62aee146 (May 2007) Perl_vload_module() wraps its call
to Perl_utilize() with ENTER/LEAVE, so there's no longer a need for callers
of Perl_load_module() to also wrap with ENTER/LEAVE.
Push a new stack in sv_recode_to_utf8

That prevents this from happening under STRESS_REALLOC:

$ ./perl -Ilib -Mencoding=johab -e '(chr(0x7f) eq "\x7f")'
Use of the encoding pragma is deprecated at -e line 0.
perl(3939) malloc: *** error for object 0x7fac20c03968: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

(That is an excerpt from t/uni/chr.t.)

It may also fix other instances of encoding.pm crashing, which I had
almost vowed not to do.  Oh well.

Constant folding is generally expected not to reallocate the stack,
because it should never need to extend it, just reduce the number of
items on it.

sv_recode_to_utf8 breaks that assumption.
Increase $PerlIO::via::VERSION to 0.14
Squash COWs in the char* typemap

Some XS modules expect to be able to modify strings passed in as char
pointers.  Copy-on-write breaks that ability.  So this commit makes
the T_PV typemap uncow mutable COWs when passing them.

const char* is now mapped to the new T_ROPV entry, to avoiding unnec-
essarily slowing it down.

Steffen Müller writes in <52912E9C.3030403@cpan.org> that the typemap
is not dual-lifed, so it is not necessary to make this 5.16-compati-
ble.  However, I had already written the patch, and I think it is good
to keep it possible to drop this typemap into a CPAN distribution.
Any self-respecting C compiler should be able to optimise away the
extra SvIsCOW(t_pv_tmp_sv) == 1 check, so there is no slowdown as a
result of compatibility.
Increase $XS::Typemap::VERSION to 0.13
Require Test::More v0.88 to use done_testing in Spec.t.

Reported in https://rt.cpan.org/Ticket/Display.html?id=87574.
First steps to resolving RT #120618, better fix for RT #120600

Commit 099ec7dcf9e085a650e6d9010c12ad9649209bf4 tried to fix RT #120618,
however it resulted in RT #120600:

    [perl #120618] Bleadperl v5.19.6-15-g099ec7d breaks ABIGAIL/Regexp-Common-2013031301.tar.gz

Which includes breakage to:

    MAUKE/Function-Parameters-1.0401.tar.gz
    ABIGAIL/Regexp-Common-2013031301.tar.gz
    DCONWAY/Regexp-Grammars-1.033.tar.gz
    AMBS/Text/Text-RewriteRules-0.25.tar.gz

To put it bluntly I didn't like the fix in 099ec7dcf9 in and it doesn't
entirely surprise me that it broke extreme modules like these.

This is a much better fix, and includes better debug output for frames
and recursion.

Both of the old strategies were flawed. The new strategy is much more
sound. Every time we recurse we create a new recursed bitmap, if
necessary copying the existing bitmap (thus treated a NULL "recursed"
pointer as an all zero bitmap). Instead of turning off the flag when
we exit, we simply "throw away" that bitmap, restoring the state of
the parent. Thus what occured in a child does not contaminate the
parent.

All of this is a bit confusing as there are two levels of recursion
at work here. First there is recursion, and pseudo-recursion in
study_chunk(), which is distinct from recursive patterns, even tho
the implementation of recursive patterns uses pseudo-recursion in
study-chunk.  Anyway, to make the new bitmap pattern work I had to
extend the frame mechanism, and add diagnostics to it, which are
visible via -Mre=Debug,ALL.

I haven't tested that this fixes the modules, I just know that it
is conceptually a much better and cleaner fix.
Test line number for (??{$str}) regexp warnings

If the (??{}) does not occur on the same line as the match operator
(e.g., if we have /foo$qr/ and $qr has (??{}) in it), we need to
make sure warnings that occur when the return value of (??{}) is
compiled use the same line number as the /.../, since conceptually
it is part of matching, not part of returning.

I tried breaking this and making the line number wrong, but all
tests passed, showing that it is untested.  Most regcomp tests are in
t/re/reg_mesg.t, but that file does not have infrastructure for check-
ing line numbers.
regexec.c: Remove redundant S_regcp_restore call

made redundant by e4bfbed3.
Avoid pointer churn in study_chunk recursion bitmap allocation

Since we can only recurse into a given paren (or the entire pattern)
once, we know that the maximum recursion depth is the number of parens
in the pattern (plus one for "whole pattern"). This means we can
preallocate one large bitmap, and then use different chunks of it
for each level. That avoids SAVEFREEPV costs for each bitmap, which
are likely short anyway. (One could imagine an optimization where a
flag somewhere lets us use the RExC_study_chunk_recursed pointer
as a bitmap, so we dont have to allocate all when we have less than
32 parens.)

This removes the "recursed" argument from study_chunk() and replaces
it with a "recursive_depth" argument which counts how deep we
are in the bitmap "stack".