The /x regular expression modifier allows the pattern to contain white space and comments,
both of which are ignored,
for improved readability.
Until now,
not all the white space characters that Unicode designates for this purpose were handled.
The additional ones now recognized are U+0085 NEXT LINE,
U+200E LEFT-TO-RIGHT MARK,
U+200F RIGHT-TO-LEFT MARK,
U+2028 LINE SEPARATOR,
and U+2029 PARAGRAPH SEPARATOR.

It is now possible to pass a parameter to use locale to specify a subset of locale categories to be locale-aware,
with the remaining ones unaffected.
See "The "use locale" pragma" in perllocale for details.

The use of these characters with /x outside bracketed character classes and when not preceded by a backslash has raised a deprecation warning since v5.18.
Now they will be ignored.
See "qr/foo/x" for the list of the five characters.

(?[ ]) is an experimental feature,
introduced in v5.18.
It operates as if /x is always enabled.
But there was a difference,
comment lines (following a # character) were terminated by anything matching \R which includes all vertical whitespace,
such as form feeds.
For consistency,
this is now changed to match what terminates comment lines outside (?[ ]),
namely a \n (even if escaped),
which is the same as what terminates a heredoc string and formats.

Previously,
the text,
unlike almost everything else,
always came out based on the current underlying locale of the program.
(Also affected on some systems is "$^E".) For programs that are unprepared to handle locale,
this can cause garbage text to be displayed.
It's better to display text that is translatable via some tool than garbage text which is much harder to figure out.

The stringification of $! and $^E will have the UTF-8 flag set when the text is actually non-ASCII UTF-8.
This will enable programs that are set up to be locale-aware to properly output messages in the user's native language.
Code that needs to continue the 5.20 and earlier behavior can do the stringification within the scopes of both 'use bytes' and 'use locale ":messages".
No other Perl operations will be affected by locale; only $! and $^E stringification.
The 'bytes' pragma causes the UTF-8 flag to not be set,
just as in previous Perl releases.
This resolves [perl #112208].

Starting regular expressions matching only once directly with the question mark delimiter is now a syntax error,
so that the question mark can be available for use in new operators.
Write m?PATTERN? instead,
explicitly using the m operator: the question mark delimiter still invokes match-once behaviour.

If you want a literal left curly bracket (also called a left brace) in a regular expression pattern,
you should now escape it by either preceding it with a backslash ("\{") or enclosing it within square brackets "[{]",
or by using \Q; otherwise a deprecation warning will be raised.
This was first announced as forthcoming in the v5.16 release; it will allow future extensions to the language to happen.

The libnet collection of modules has been upgraded from version 1.25 to 1.27.

There are only whitespace changes to the installed files.

A mismatch between the documentation and the code in utf8::downgrade() was fixed in favour of the documentation.
The optional second argument is now correctly treated as a perl boolean (true/false semantics) and not as an integer.

The Locale-Codes collection of modules has been upgraded from version 3.30 to 3.31.

Fixed a bug in the scripts used to extract data from spreadsheets that prevented the SHP currency code from being found.
[cpan #94229]

(F) You defined a character name which had multiple space characters in a row.
Change them to single spaces.
Usually these names are defined in the :alias import argument to use charnames,
but they could be defined by a translator installed into $^H{charnames}.
See "CUSTOM ALIASES" in charnames.

(F) You defined a character name which ended in a space character.
Remove the trailing space(s).
Usually these names are defined in the :alias import argument to use charnames,
but they could be defined by a translator installed into $^H{charnames}.
See "CUSTOM ALIASES" in charnames.

Although defined %hash is false on a plain not-yet-used hash,
it becomes true in several non-obvious circumstances,
including iterators,
weak references,
stash names,
even remaining true after undef %hash.
These things make defined %hash fairly useless in practice,
so it now generates a fatal error.

If you had defined %Foo::Bar::QUUX to check whether such a package variable exists then that's never really been reliable, and isn't a good way to enquire about the features of a package, or whether it's loaded, etc.

(D deprecated, regexp) You used a literal "{" character in a regular expression pattern. You should change to use "\{" instead, because a future version of Perl (tentatively v5.26) will consider this to be a syntax error. If the pattern delimiters are also braces, any matching right brace ("}") should also be escaped to avoid confusing the parser, for example,

(D deprecated) You defined a character name which contained a no-break space character. Change it to a regular space. Usually these names are defined in the :alias import argument to use charnames, but they could be defined by a translator installed into $^H{charnames}. See "CUSTOM ALIASES" in charnames.

NeXTSTEP was proprietary OS bundled with NeXT's workstations in the early to mid 90's; OPENSTEP was an API specification that provided a NeXTSTEP-like environment on a non-NeXTSTEP system. Both are now long dead, so support for building Perl on them has been removed.

On OpenBSD, Perl will now default to using the system malloc due to the security features it provides. Perl's own malloc wrapper has been in use since v5.14 due to performance reasons, but the OpenBSD project believes the tradeoff is worth it and would prefer that users who need the speed specifically ask for it.

Perl now tries to keep the locale category LC_NUMERIC set to "C" except around operations that need it to be set to the program's underlying locale. This protects the many XS modules that cannot cope with the decimal radix character not being a dot. Prior to this release, Perl initialized this category to "C", but a call to POSIX::setlocale() would change it. Now such a call will change the underlying locale of the LC_NUMERIC category for the program, but the locale exposed to XS code will remain "C". There is an API under development for those relatively few modules that need to use the underlying locale. This API will be nailed down during the course of developing v5.21. Send email to mailto:perl5-porters@perl.org for guidance.

A new macro isUTF8_CHAR has been written which efficiently determines if the string given by its parameters begins with a well-formed UTF-8 encoded character.

index() and rindex() no longer crash when used on strings over 2GB in size. [perl #121562].

A small previously intentional memory leak in PERL_SYS_INIT/PERL_SYS_INIT3 on Win32 builds was fixed. This might affect embedders who repeatedly create and destroy perl engines within the same process.

POSIX::localeconv() now returns the data for the program's underlying locale even when called from outside the scope of use locale.

POSIX::localeconv() now works properly on platforms which don't have LC_NUMERIC and/or LC_MONETARY, or for which Perl has been compiled to disregard either or both of these locale categories. In such circumstances, there are now no entries for the corresponding values in the hash returned by localeconv().

POSIX::localeconv() now marks appropriately the values it returns as UTF-8 or not. Previously they were always returned as a bytes, even if they were supposed to be encoded as UTF-8.

On Microsoft Windows, within the scope of use locale, the following POSIX character classes gave results for many locales that did not conform to the POSIX standard: [[:alnum:]], [[:alpha:]], [[:blank:]], [[:digit:]], [[:graph:]], [[:lower:]], [[:print:]], [[:punct:]], [[:upper:]], [[:word:]], and [[:xdigit:]]. These are because the underlying Microsoft implementation does not follow the standard. Perl now takes special precautions to correct for this.

Due to an oversight, the value specified through -Dtargetsh to Configure would end up being ignored by some of the build process. This caused perls cross-compiled for Android to end up with defective versions of system(), exec() and backticks: the commands would end up looking for /bin/sh instead of /system/bin/sh, and so would fail for the vast majority of devices, leaving $! as ENOENT.

qr(...\(...\)...), qr[...\[...\]...], and qr{...\{...\}...} now work. Previously it was impossible to escape these three left-characters with a backslash within a regular expression pattern where otherwise they would be considered metacharacters, and the pattern opening delimiter was the character, and the closing delimiter was its mirror character.

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.