Regular expression objects are now dumped in a form closer to their original source,
eg.
qr/abc/i is dumped as exactly that instead of qr/(?^i:abc)/ .
[perl #82948]

Dumping of hash keys is now more consistent between the XS and perl implementations of Data::Dumper,
including how the quotekeys option behaves.
This may make tests that depend on the exact output of Data::Dumper to fail.
[perl #120384]

The sv argument in "sv_2pv_flags" in perlapi,
"sv_2iv_flags" in perlapi,
"sv_2uv_flags" in perlapi,
and "sv_2nv_flags" in perlapi and their older wrappers sv_2pv,
sv_2iv,
sv_2uv,
sv_2nv,
is now non-NULL.
Passing NULL now will crash.
When the non-NULL marker was introduced en masse in 5.9.3 the functions were marked non-NULL,
but since the creation of the SV API in 5.0 alpha 2,
if NULL was passed,
the functions returned 0 or false-type values.
The code that supports sv argument being non-NULL dates to 5.0 alpha 2 directly,
and indirectly to Perl 1.0 (pre 5.0 api).
The lack of documentation that the functions accepted a NULL sv was corrected in 5.11.0 and between 5.11.0 and 5.19.5 the functions were marked NULLOK.
As an optimization the NULLOK code has now been removed,
and the functions became non-NULL marked again,
because core getter-type macros never pass NULL to these functions and would crash before ever passing NULL.

The only way a NULL sv can be passed to sv_2*v* functions is if XS code directly calls sv_2*v*.
This is unlikely as XS code uses Sv*V* macros to get the underlying value out of the SV.
One possible situation which leads to a NULL sv being passed to sv_2*v* functions,
is if XS code defines its own getter type Sv*V* macros,
which check for NULL before dereferencing and checking the SV's flags through public API Sv*OK* macros or directly using private API SvFLAGS,
and if sv is NULL,
then calling the sv_2*v functions with a NULL litteral or passing the sv containing a NULL value.

semctl(...,
SETVAL,
...) would set the semaphore to the top 32-bits of the supplied integer instead of the bottom 32-bits on 64-bit big-endian systems.
[perl #120635]

A regression since v5.18.0 has been fixed in which qr/[[:^ascii:]]/d failed to match any character in the range \x80 - \xFF if its surrounding character class contained anything else.
(That is,
the bug didn't happen if the [:^ascii:] was the only element of the character class.) [perl #120799]

readdir() now only sets $! on error.
$! is no longer set to EBADF when then terminating undef is read from the directory unless the system call sets $!.
[perl #118651]

open with layers that load modules (e.g.,
"<:encoding(utf8)") no longer runs the risk of crashing due to stack corruption.

When a reference to a reference to an overloaded object was returned from a regular expression (??{...}) code block,
an incorrect implicit dereference could take place if the inner reference had been returned by a code block previously.

A tied variable returned from (??{...}) sees the inner values of match variables (i.e.,
the $1 etc.
from any matches inside the block) in its FETCH method.
This was not the case if a reference to an overloaded object was the last thing assigned to the tied variable.
Instead,
the match variables referred to the outer pattern during the FETCH call.

Perl 5.18 broke autoloading via ->SUPER::foo method calls by looking up AUTOLOAD from the current package rather than the current package's superclass.
This has been fixed.
[perl #120694]

A longstanding bug causing do {} until CONSTANT,
where the constant holds a true value,
to read unallocated memory has been resolved.
This would usually happen after a syntax error.
In past versions of Perl it has crashed intermittently.
[perl #72406]

Fix HP-UX $!
failure.
HP-UX strerror() returns an empty string for an unknown error code.
This caused an assertion to fail under DEBUGGING builds.
This patch removes the assertion and changes the return into a non-empty string indicating the errno is for an unknown error.

Fix unexpected tainting via regexp using locale.
Previously,
under certain conditions,
the use of character classes could cause tainting when it shouldn't.
Some character classes are locale-dependent,
but before this patch,
sometimes tainting was happening even for character classes that don't depend on the locale.
[perl #120675]

Under certain conditions,
Perl would throw an error if in an lookbehind assertion in a regexp,
the assertion referred to a named subpattern,
complaining the lookbehind was variable when it wasn't.
This has been fixed.
[perl #120600],
[perl #120618].
The current fix may be improved on in the future.

The list above is almost certainly incomplete as it is automatically generated from version control history.
In particular,
it does not include the names of the (very much appreciated) contributors who reported issues to the Perl bug tracker.

Many of the changes included in this version originated in the CPAN modules included in Perl's core.
We're grateful to the entire CPAN community for helping Perl to flourish.

For a more complete list of all of Perl's historical contributors,
please see the AUTHORS file in the Perl source distribution.

If you find what you think is a bug,
you might check the articles recently posted to the comp.lang.perl.misc newsgroup and the perl bug database at https://rt.perl.org/ .
There may also be information at http://www.perl.org/ ,
the Perl Home Page.

If you believe you have an unreported bug,
please run the perlbug program included with your release.
Be sure to trim your bug down to a tiny but sufficient test case.
Your bug report,
along with the output of perl -V,
will be sent off to perlbug@perl.org to be analysed by the Perl porting team.

If the bug you are reporting has security implications,
which make it inappropriate to send to a publicly archived mailing list,
then please send it to perl5-security-report@perl.org.
This points to a closed subscription unarchived mailing list,
which includes all the core committers,
who will be able to help assess the impact of issues,
figure out a resolution,
and help co-ordinate the release of patches to mitigate or fix the problem across all platforms on which Perl is supported.
Please only use this address for security issues in the Perl core,
not for modules independently distributed on CPAN.