Use IVSIZE not HAS_QUAD to enable "long long" formats in sv_vcatpvfn_flags().

Without this, enabling HAS_QUAD on 32 bit IV systems causes a lot of test
failures. Potentially those failures could be addressed, but it seems like
a lot more work for little gain.
Use IVSIZE not HAS_QUAD to enable 'q' and 'Q' formats in pack.

Whilst the code for 'q' and 'Q' in pp_pack is itself well behaved if enabled
on a perl with 32 bit IVs (using SvNV instead of SvIV and SvUV), the
regression tests are not. Several tests use an eval of "pack 'q'" to
determine if 64 bit integer support is available (instead of
$Config{ivsize}), and t/op/pack.t fails many tests. While these could be
fixed (or skipped), unfortunately the approach of evaling "pack 'q'" is
fairly popular on CPAN, so the breakage isn't just in the perl core, and
might also be present in code we can't see or submit patches for.
The choice of 7 or 13 byte extended UTF-8 should be based on UVSIZE.

Previously it was based on HAS_QUAD, which is not (as) correct.
Eliminate POPq, POPuq, TOPq, TOPuq, dPOPqv, dTOPqv, qPOPuqv, dTOPuqv.

These shortcut macros are unused in the core, and unused by any code on CPAN.
If any XS code we can't see *is* using them, it will now fail to compile, and
can easily be fixed by replacing the macros with their expansion.
Merge fixes needed to build with 32 bit IVs and HAS_QUAD defined.

However, don't actually eliminate the #undef HAS_QUAD for 32 bit IVs, as
the costs (in CPAN breakage) look to be higher than the gains.
(See RT #119753 for more detailed analysis.)
Upgrade CPAN from version 2.00 to 2.03-TRIAL
Rewrap one perldiag entry for better splain output

The right margin is slightly less uneven this way (once the pod
formatting is stripped).
[perl #119501] \(1+2) always referencing the same sv

2484f8dbbb hid the fact that constant folding happens by making 1+2
fold to  a PADTMP, an SV that is never used as an lvalue and gets cop-
ied if one tries to use it that way.

The PADTMP mechanism is what allows \"$x" to return a new value each
time, even though ops like "$x" actually reuse the same scalar repeat-
edly to return values.

Because \ copies PADTMPs, \(1+2) ends up folding 1+2 to 3 (marked
PADTMP), which is then copied by the \ at compile time.  (Constant
folding works by evaluating certain ops at compile time and then
inlining their returned value.)  The result is that we have a folded
\3 where 3 is *not* marked PADTMP (the reference is, instead); hence
\(1+2) gives the same scalar each time, producing a value that can be
modified, affecting future evaluations.

The solution is to skip folding \ if its argument is a PADTMP.
perlhack: Make MAINTENANCE BRANCHES a link
perldelta - Fill in one more item and add currently remaining possible TODOs
RT-119817 - Treat =back as the end of a warning description.

This keeps any trailing data in the file from showing up as part
of the last warning's description.
Upgrade parent from version 0.227 to 0.228
Use non-dev version number in IO::Socket

There was no need for 80d2c56d79 to use a dev number. The IO distribution's
modules all have differing version numbers, mostly all well ahead of the
last CPAN release (UPSTREAM is 'blead' anyway), and no others are dev
numbers.
perldelta - Three module upgrades which haven't come from new CPAN releases
perldelta for f1deee3312
Sort the contents of %Modules in Porting/Maintainers.pl

(No changes other than the ordering of the entries.)
depend on the new win32 sys/errno2.h header
perldelta: Two to-dos that don’t deserve mention

9cefd268 [perl #118747] Allow in-place s///g when !!PL_sawampersand
c04e4151 op.c:leave_scope: use mg_free before sv_force_normal [#119295]

In both cases, it is a module relying on undocumented internals.

In the former, we do have an optimisation kicking in in cases where it
didn’t in 5.18 and earlier.  But those cases are rare enough that an
entry in ‘Performance Enhancements’ would be misleading.

In the latter, the order in which clearing and ‘free’ magic are trig-
gered is more predictable, but I don’t believe that has ever been
guaranteed, and only creepy modules will be affected by it.
perldelta for 650b1534
perldelta for acb340504/#119501