Update Changes fr Module-CoreList and bump to version 2.72
Sync Module-CoreList in Maintainers.pl for CPAN release
[perl #113718] Add inline.h

We can put static inline functions here, and they can depend on
function prototypes and struct definitions from other header
files.
Use static inline functions for SvREFCNT_inc

This avoids the need to repeat the macros in GCC and non-GCC versions.
For non-GCC compilers capable of inlining, this should speed things up
slightly, too, as PL_Sv is no longer needed.
Use fast SvREFCNT_dec for non-GCC
Static inline functions for SvPADTMP and SvPADSTALE

This allows non-GCC compilers to have assertions and avoids
repeating the macros.
Move S_CvDEPTHp from cv.h to inline.h; shrink macros

This allows us to use assert() inside S_CvDEPTHp, so we no longer need
GCC and non-GCC variants of the macro that calls it.
[Merge] Enter inline.h

This is a home for static inline functions that cannot go in other
headers because they depend on proto.h or struct definitions.

This allows us to avoid repeating macros with GCC and non-GCC ver-
sions.  It also makes it easier to avoid evaluating macro argu-
ments twice.

I’ve moved just enough things into it to offset the additional lines
added by the comments at the top.  The ‘net code removal’ of this
branch is 4 lines.
Move PAD(LIST) typedefs to perl.h

otherwise they can only be used in some header files.
Use PADLIST in more places

Much code relies on the fact that PADLIST is typedeffed as AV.
PADLIST should be treated as a distinct type.
Stop padlists from being AVs

In order to fix a bug, I need to add new fields to padlists.  But I
cannot easily do that as long as they are AVs.

So I have created a new padlist struct.

This not only allows me to extend the padlist struct with new members
as necessary, but also saves memory, as we now have a three-pointer
struct where before we had a whole SV head (3-4 pointers) + XPVAV (5
pointers).

This will unfortunately break half of CPAN, but the pad API docs
clearly say this:

    NOTE: this function is experimental and may change or be
    removed without notice.

This would have broken B::Debug, but a patch sent upstream has already
been integrated into blead with commit 9d2d23d981.
Increase $B::Xref::VERSION from 1.03 to 1.04
Fix format closure bug with redefined outer sub

CVs close over their outer CVs.  So, when you write:

my $x = 52;
sub foo {
  sub bar {
    sub baz {
      $x
    }
  }
}

baz’s CvOUTSIDE pointer points to bar, bar’s CvOUTSIDE points to foo,
and foo’s to the main cv.

When the inner reference to $x is looked up, the CvOUTSIDE chain is
followed, and each sub’s pad is looked at to see if it has an $x.
(This happens at compile time.)

It can happen that bar is undefined and then redefined:

undef &bar;
eval 'sub bar { my $x = 34 }';

After this, baz will still refer to the main cv’s $x (52), but, if baz
had  ‘eval '$x'’ instead of just $x, it would see the new bar’s $x.
(It’s not really a new bar, as its refaddr is the same, but it has a
new body.)

This particular case is harmless, and is obscure enough that we could
define it any way we want, and it could still be considered correct.

The real problem happens when CVs are cloned.

When a CV is cloned, its name pad already contains the offsets into
the parent pad where the values are to be found.  If the outer CV
has been undefined and redefined, those pad offsets can be com-
pletely bogus.

Normally, a CV cannot be cloned except when its outer CV is running.
And the outer CV cannot have been undefined without also throwing
away the op that would have cloned the prototype.

But formats can be cloned when the outer CV is not running.  So it
is possible for cloned formats to close over bogus entries in a new
parent pad.

In this example, \$x gives us an array ref.  It shows ARRAY(0xbaff1ed)
instead of SCALAR(0xdeafbee):

sub foo {
    my $x;
format =
@
($x,warn \$x)[0]
.
}
undef &foo;
eval 'sub foo { my @x; write }';
foo
__END__

And if the offset that the format’s pad closes over is beyond the end
of the parent’s new pad, we can even get a crash, as in this case:

eval
'sub foo {' .
'{my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}'x999
. q|
    my $x;
format =
@
($x,warn \$x)[0]
.
}
|;
undef &foo;
eval 'sub foo { my @x; my $x = 34; write }';
foo();
__END__

So now, instead of using CvROOT to identify clones of
CvOUTSIDE(format), we use the padlist ID instead.  Padlists don’t
actually have an ID, so we give them one.  Any time a sub is cloned,
the new padlist gets the same ID as the old.  The format needs to
remember what its outer sub’s padlist ID was, so we put that in the
padlist struct, too.
More PAD APIs

If we are making padlists their own type, and no longer AVs, it makes
sense to add APIs for pads, too, so that CPAN code that needs to
change now will only have to change once if we ever stop pads them-
selves from being AVs.

There is no reason pad names have to be SVs, so I am adding sep-
arate APIs for pad names, too.  The AV containing pad names is
now officially a PADNAMELIST, which is accessed, not via
*PADLIST_ARRAY(padlist), but via PADLIST_NAMES(padlist).

Future optimisations may even merge the padlist with its name list so
I have also added macros to access the parts of the name list directly
from the padlist.
pad.c: CvPADLIST doc update
Use new types for comppad and comppad_name

I know that a few times I’ve looked at perl source files to find out
what type to use in ‘<type> foo = PL_whatever’.  So I am changing
intrpvar.h as well as the api docs.
pad.c: Use PAD_ARRAY rather than AvARRAY in curpad docs
pad.c: CvPADLIST docs: one more thing
Increase $B::VERSION to 1.38
Increase $XS:APItest::VERSION to 0.43