The overloading logic in Carp got confused on perl 5.6 by the overload
module not setting $VERSION. As the overload-is-loaded check controls
the use of overload::StrVal(), check for that sub being defined rather
than checking $VERSION.

On older Perls, a call of the form $undef->() generates an "uninitialized
value" warning before dying. The new overloaded-object logic in Carp
assumes the more modern behaviour, that the undefinedness causes an
exception directly with no separate warning. To restore compatibility of
Carp to older Perls, check explicitly for definedness of $RefArgFormatter
rather than relying on the exception.

Commit 8c34e50d inadvertently caused DESTROY caches not to be
reset when UNIVERSAL::DESTROY changes. Normally, a change to
a method will cause mro_method_changed_in to be called on all
subclasses, but mro.c cheats for UNIVERSAL and just does
++PL_sub_generation. So clearing the DESTROY cache explicitly
in mro_method_changed_in is clearly not enough.

The methods can be used as methods on File::Spec::Unix, as methods
inherited by File::Spec::$notunix, and as standalone functions. Quite a
lot of complexity comes from making them work in all of these roles,
without the compatibility damaging the performance of any of them.
The methods therefore need to check their invocant, using C code
where the invocant is File::Spec::Unix, and calling other methods if
it is not, so that they play nicely in composition with other methods.
The standalone function is another XS entry point, entirely unencumbered
by OO interface paraphernalia. File::Spec::Functions is modified to
pick up the separate function version.

There is new logic for File::Spec to fall back to pure Perl, in the way
that Cwd.pm already does, for XS-impaired systems.

Both t/001-basic.t and what was t/004-nolinenumbers.t were trying to write to
a 't/XSTest.c' file. When run in parallel, this was causing problems when
TEST_JOBS >= 1 (2 on some boxes, 4 on dromedary).

Since all that t/004-nolinenumbers.t was ever trying to do was to run
process_file() without line numbers -- a case not exercised prior to my
2009-11 refactoring/test additions -- the simplest way to avoid these
problems is to stuff the tests from t/004 into t/001 and delete t/001.

(There isn't a release type called "BLEAD": we have either "BLEAD-POINT" or
"BLEAD-FINAL". There is one reference to "BLEAD" remaining, which I think
in the context is intended to mean "either BLEAD-POINT or BLEAD-FINAL".)

1. Commit the work as it's done to the local release branch
2. Push those commits to the remote release branch (creating it in the
process)
3. Create a tag identifying the last commit in the release branch
4. Publish that release tag to the public repository
5. Merge the [local] release branch commits into the local blead branch
6. Push those merged commits to the remote blead branch

A recently added query in the RMG asked why it was necessary to push the
work so far (step (2) above), given that we're working on a release branch.

In an email discussion with RJBS we reached the conclusion that it is
indeed unnecessary: the merge in step (5) operates purely on the local
release branch, so there is no need to push anything first.

The release tag still needs to be pushed (step (4)), though, because in a
default Git configuration "git push" only pushes commits, not tags as well.
However, if we omit step (2) then it makes more sense to delay step (4)
until after steps (5) and (6) otherwise we are publishing a tag identifying
a commit that hasn't been pushed anywhere public yet.

The above sequence of steps has therefore been changed to:

1. Commit the work as it's done to the local release branch
2. Create a tag identifying the last commit in the local release branch
3. Merge the local release branch commits into the local blead branch
4. Push those merged commits to the remote blead branch
5. Publish the tag (which identifies the last of those pushed commits)
to the public repository

For the same reasons, the "git push origin ...." when disarming
patchlevel.h in non-BLEAD-POINT releases has been removed since we're still
on the release branch at this point in the process.

Also, since we now never push anything to a remote release branch, there is
no longer any need to delete it. Only the local release branch needs
deleting.

Finally, the last "git commit" instruction in the RMG (regarding copying
perldelta.pod to blead for MAINT and BLEAD-FINAL releases) was lacking a
"git push origin ....": we're no longer on the release branch by this stage
of the process.

This creates a function to display a list of code points that are passed
in. It uses hex for non-ASCII graphics and otherwise outputs the
characters, perhaps as ranges. It makes reading the output a lot
easier. Previously, there could be discrepancies in if the output was
in utf8 vs what the file handle thought, and even when there was no
such discrepancy, the upper Latin1 characters were displayed as if the
locale is Latin1, which it likely wasn't, so the graphics were
misleading.

In commit 32e8aa3fdb11b64c2a141bf56441761d978fd17b, I forgot that the
POSIX standard allows \d ([:digit:]) to match either the 10 ASCII
digits, or those plus another 10 locale-dependent ones. This new commit
tests that the number matched is either 10 or 20, and if not 10, then
\d doesn't have to be a subset of [:xdigit:], so skip that test.

All modified files in UPSTREAM=>cpan/undef distros are now listed as CUSTOMIZED

All of these modifications already had, or now have, rt.cpan.org tickets
for them requesting that the changes be merged upstream, and the ticket
numbers are now listed in Maintainers.pl alongside each list of CUSTOMIZED
files.

The goal is ultimately to get new CPAN distros rolled for all of these so
that we have no CUSTOMIZED files left (other than a couple of special
cases - libnet, Module::Build and podlators), but there is nothing we can
do at our end to make this happen.

0abd0d78 removed making tries under /di matching, the reason being that
it was broken for many of the upper Latin1 characters, the ones whose
matches aren't fully known until run-time. For example under /di, LATIN
CAPITAL LETTER A WITH GRAVE caselessly matches LATIN SMALL LETTER A WITH
GRAVE if and only if the target string is encoded in UTF-8. Under /ui
matching, these always match, and so tries are constructed for them.

But if a regnode doesn't contain any of the 61 problematic characters (nor
the sequence 'ss' (upper- and/or lowercase), what it matches is fully
known at compile time, and so should be trie-able as-is.

This commit merely keeps track of if any character in the regnode is one
of the 61 or the 'ss' sequence, and if not, changes its type to be /ui
and hence trie-able.

This changes the declarations of two variables to also initialize them,
removing the initializing statements further down. This will be helpful
in a future commit, besides being generally slightly faster.

Commit cb251201d6 inadvertently broke the embedding of the manifest file
in miniperl.exe by changing the target which builds miniperl.exe and hence
the value of $@, which is used in the EMBED_EXE_MANI macro.

It isn't hugely important since the .exe works fine with the .manifest left
alongside it anyway (and miniperl.exe isn't even an installed file either),
but fixing it saves having to .gitignore the .manifest file which was being
left behind rather than embedded and deleted.

We can do this nicely in dmake-speak; unfortunately nmake's version of the
same isn't as nice since it can't handle macros in macro substitutions.

This resolves the last remaining issue in ticket #78194, that
newRV is supposedly buggy because it doesn’t copy its referent.
The full implications of the PADTMP are not explained anywhere in
the API docs, and even XSUBs shouldn’t have to worry about special
handling. (E.g., what if they do SvREFCNT_dec(SvRV(sv)); SvRV(sv)=...?)

This commit makes Devel::Peek::Dump modify the op tree to allow it to
dump arrays and hashes directly via Dump @array and Dump %hash. It
also puts other operators in rvalue context, allowing the return value
of rvalue substr for instance to be dumped, making Devel::Peek more
useful as a debugging tool.

Since a future commit (to fix the rest of #78194) is likely to make
pp_entersub copy PADTMPs (operator return values) for XSUBs (it
already happens for Perl subs as of b479c9f2a), to the detriment of
Devel::Peek’s usefulness, I also made it inline Dump as a custom op.

This does introduce a backward-incompatible change, in that both argu-
ments to Dump are now in scalar context, and the number of arguments
is checked at compile time instead of run time (still run time for
&Dump(...)), but I think it is worth it.

The win32/config.[gv]c files are generally kept up to date these days (and
we have tests to check that) so no changes are required in them.

The win32/config_H.[gv]c files are regenerated as per instructions in the
win32/Makefile and win32/makefile.mk, being careful to restore a couple of
things otherwise lost from the config_H.gc file. The files are now in sync
with the top-level master configuration file, config_h.SH.