=over 4
-=item * C<.> no longer in C<@INC>
+=item * C<"."> no longer in C<@INC>
-The current modules, and for the execution of scripts. See the section
-L<< Removal of the current directory (C<.>) from C<@INC> >> for the full details.
+For security reasons, the current directory (C<".">) is no longer included
+by default at the end of the module search path (C<@INC>). This may have
+widespread implications for the building, testing and installing of
+modules, and for the execution of scripts. See the section
+L<< Removal of the current directory (C<".">) from C<@INC> >>
+for the full details.
=item * C<do> may now warn
-C<do> now gives a mandatory warning when it fails to load a file which it
-would have loaded had C<.> been in C<@INC>.
+C<do> now gives a deprecation warning when it fails to load a file which
+it would have loaded had C<"."> been in C<@INC>.
=item * In regular expression patterns, a literal left brace C<"{">
should be escaped
=head1 Core Enhancements
-=head2 New regular expression modifier C</xx>
-
-Specifying two C<x> characters to modify a regular expression pattern
-does everything that a single one does, but additionally TAB and SPACE
-characters within a bracketed character class are generally ignored and
-can be added to improve readability, like
-S<C</[ ^ A-Z d-f p-x ]/xx>>. Details are at
-L<perlre/E<sol>x and E<sol>xx>.
-
-=head2 New Hash Function For 64-bit Builds
-
-We have switched to a hybrid hash function to better balance
-performance for short and long keys.
+=head2 Lexical subroutines are no longer experimental
-For short keys, 16 bytes and under, we use an optimised variant of
-One At A Time Hard, and for longer keys we use Siphash 1-3. For very
-long keys this is a big improvement in performance. For shorter keys
-there is a modest improvement.
+Using the C<lexical_subs> feature introduced in v5.18 no longer emits a warning. Existing
+code that disables the C<experimental::lexical_subs> warning category
+that the feature previously used will continue to work. The
+C<lexical_subs> feature has no effect; all Perl code can use lexical
+subroutines, regardless of what feature declarations are in scope.
=head2 Indented Here-documents
-This adds a new modifier '~' to here-docs that tells the parser
+This adds a new modifier C<"~"> to here-docs that tells the parser
that it should look for /^\s*$DELIM\n/ as the closing delimiter.
These syntaxes are all supported:
<<~ "EOF";
<<~ `EOF`;
-The '~' modifier will strip, from each line in the here-doc, the
+The C<"~"> modifier will strip, from each line in the here-doc, the
same whitespace that appears before the delimiter.
-Newlines will be copied as is, and lines that don't include the
+Newlines will be copied as-is, and lines that don't include the
proper beginning whitespace will cause perl to croak.
For example:
prints "Hello there\n" with no leading whitespace.
+=head2 New regular expression modifier C</xx>
+
+Specifying two C<"x"> characters to modify a regular expression pattern
+does everything that a single one does, but additionally TAB and SPACE
+characters within a bracketed character class are generally ignored and
+can be added to improve readability, like
+S<C</[ ^ A-Z d-f p-x ]/xx>>. Details are at
+L<perlre/E<sol>x and E<sol>xx>.
+
=head2 @{^CAPTURE}, %{^CAPTURE}, and %{^CAPTURE_ALL}
C<@{^CAPTURE}> exposes the capture buffers of the last match as an
-array. So C<$1> is C<${^CAPTURE}[0]>. This is a more efficient equivalent
+array. So C<$1> is C<${^CAPTURE}[0]>. This is a more efficient equivalent
to code like C<substr($matched_string,$-[0],$+[0]-$-[0])>, and you don't
-have to keep track of the C<$matched_string> either. This variable has no
-single character equivalent. Note like the other regex magic variables
+have to keep track of the C<$matched_string> either. This variable has no
+single character equivalent. Note, like the other regex magic variables
the contents of this variable is dynamic, if you wish to store it beyond
the lifetime of the match you must copy it to another array.
-C<%{^CAPTURE}> is the equivalent to C<%+> (ie named captures). Other than
+C<%{^CAPTURE}> is the equivalent to C<%+> (I<i.e.>, named captures). Other than
being more self documenting there is no difference between the two forms.
-C<%{^CAPTURE_ALL}> is the equivalent to C<%-> (ie all named captures).
+C<%{^CAPTURE_ALL}> is the equivalent to C<%-> (I<i.e.>, all named captures).
Other than being more self documenting there is no difference between the
two forms.
+=head2 Declaring a reference to a variable
+
+As an experimental feature, Perl now allows the referencing operator to come
+after L<C<my()>|perlfunc/my>, L<C<state()>|perlfunc/state>,
+L<C<our()>|perlfunc/our>, or L<C<local()>|perlfunc/local>. This syntax must
+be enabled with C<use feature 'declared_refs'>. It is experimental, and will
+warn by default unless C<no warnings 'experimental::refaliasing'> is in effect.
+It is intended mainly for use in assignments to references. For example:
+
+ use experimental 'refaliasing', 'declared_refs';
+ my \$a = \$b;
+
+See L<perlref/Assigning to References> for more details.
+
=head2 Unicode 9.0 is now supported
A list of changes is at L<http://www.unicode.org/versions/Unicode9.0.0/>.
compound forms, like C<\p{sc=I<script>}> are unchanged. See
L<perlunicode/Scripts>.
-=head2 Declaring a reference to a variable
-
-As an experimental feature, Perl now allows the referencing operator to come
-after L<C<my()>|perlfunc/my>, L<C<state()>|perlfunc/state>,
-L<C<our()>|perlfunc/our>, or L<C<local()>|perlfunc/local>. This syntax must
-be enabled with C<use feature 'declared_refs'>. It is experimental, and will
-warn by default unless C<no warnings 'experimental::refaliasing'> is in effect.
-It is intended mainly for use in assignments to references. For example:
-
- use experimental 'refaliasing', 'declared_refs';
- my \$a = \$b;
-
-See L<perlref/Assigning to References> for more details.
-
=head2 Perl can now do default collation in UTF-8 locales on platforms
that support it
=head2 Better locale collation of strings containing embedded C<NUL>
characters
-In locales that have multi-level character weights, these are now
+In locales that have multi-level character weights, C<NUL>s are now
ignored at the higher priority ones. There are still some gotchas in
some strings, though. See
L<perllocale/Collation of strings containing embedded C<NUL> characters>.
-=head2 Lexical subroutines are no longer experimental
-
-Using the C<lexical_subs> feature introduced in v5.18 no longer emits a warning. Existing
-code that disables the C<experimental::lexical_subs> warning category
-that the feature previously used will continue to work. The
-C<lexical_subs> feature has no effect; all Perl code can use lexical
-subroutines, regardless of what feature declarations are in scope.
-
=head2 C<CORE> subroutines for hash and array functions callable via
reference
(C<< my $k = \&CORE::keys; $k-E<gt>(\%hash) >>). Previously they could only be
used when inlined.
-=head2 create a safer utf8_hop() called utf8_hop_safe()
-
-Unlike utf8_hop(), utf8_hop_safe() won't navigate before the beginning or after
-the end of the supplied buffer.
-
-=head1 Security
-
-=head2 '.' and @INC
-
-Since time immemorial Perl has, as a last resort, loaded libraries
-from the current directory. For security reasons this is no longer the
-case. This is controlled by the C<@INC> variable, and it no longer
-defaults to containing C<.> as its last element.
+=head2 New Hash Function For 64-bit Builds
-If you want to disable this behavior at compile-time, build perl with
-C<-Udefault_inc_excludes_dot> (C<-Ddefault_inc_excludes_dot> being the
-default now).
+We have switched to a hybrid hash function to better balance
+performance for short and long keys.
-If you'd like to add C<.> back to C<@INC> at runtime set
-C<PERL_USE_UNSAFE_INC=1> in the environment before starting
-perl. Setting it to 1 restores C<.> in the C<@INC> when perl otherwise
-lacks it.
+For short keys, 16 bytes and under, we use an optimised variant of
+One At A Time Hard, and for longer keys we use Siphash 1-3. For very
+long keys this is a big improvement in performance. For shorter keys
+there is a modest improvement.
-Various toolchain modules will set C<PERL_USE_UNSAFE_INC=1>
-themselves. E.g. L<Test::Harness> sets it since loading modules from a
-relative path is a common idiom in test code. If you find that you
-have C<.> in C<@INC> on a perl built with default settings it's likely
-that your code is being invoked by a toolchain module of some sort.
+=head1 Security
-=head2 Removal of the current directory (C<.>) from C<@INC>
+=head2 Removal of the current directory (C<".">) from C<@INC>
-The perl binary includes a default set of paths in C<@INC>. Historically
-it has also included the current directory (C<.>) as the final entry,
-unless run with taint mode enabled (C<perl -T>). While convenient, this has
+The perl binary includes a default set of paths in C<@INC>. Historically
+it has also included the current directory (C<".">) as the final entry,
+unless run with taint mode enabled (C<perl -T>). While convenient, this has
security implications: for example, where a script attempts to load an
optional module when its current directory is untrusted (such as F</tmp>),
it could load and execute code from under that directory.
-Starting with v5.26.0, C<.> is always removed by default, not just under
-tainting. This has major implications for installing modules and executing
+Starting with v5.26, C<"."> is always removed by default, not just under
+tainting. This has major implications for installing modules and executing
scripts.
The following new features have been added to help ameliorate these
=item * C<Configure -Udefault_inc_excludes_dot>
There is a new C<Configure> option, C<default_inc_excludes_dot> (enabled
-by default) which builds a perl executable without C<.>; unsetting this
-option using C<-U> reverts perl to the old behaviour. This may fix your
+by default) which builds a perl executable without C<".">; unsetting this
+option using C<-U> reverts perl to the old behaviour. This may fix your
path issues but will reintroduce all the security concerns, so don't
build a perl executable like this unless you're I<really> confident that
such issues are not a concern in your environment.
-=item * C<$PERL_USE_UNSAFE_INC>
+=item * C<PERL_USE_UNSAFE_INC>
There is a new environment variable recognised by the perl interpreter.
-If this variable has the value C<1> when the perl interpreter starts up,
-then C<.> will be automatically appended to C<@INC> (except under tainting).
+If this variable has the value 1 when the perl interpreter starts up,
+then C<"."> will be automatically appended to C<@INC> (except under tainting).
This allows you restore the old perl interpreter behaviour on a
-case-by-case basis. But note that this intended to be a temporary crutch,
+case-by-case basis. But note that this is intended to be a temporary crutch,
and this feature will likely be removed in some future perl version.
It is currently set by the C<cpan> utility and C<Test::Harness> to
-ease installation of CPAN modules which have not been updated handle the
-lack of dot. Once again, don't use this unless you are sure that this
+ease installation of CPAN modules which have not been updated to handle the
+lack of dot. Once again, don't use this unless you are sure that this
will not reintroduce any security concerns.
=item * A new mandatory warning issued by C<do>.
While it is well-known that C<use> and C<require> use C<@INC> to search
for the file to load, many people don't realise that C<do "file"> also
-searches C<@INC> if the file is a relative path. With the removal of C<.>,
+searches C<@INC> if the file is a relative path. With the removal of C<".">,
a simple C<do "file.pl"> will fail to read in and execute C<file.pl> from
-the current directory. Since this is commonly expected behaviour, a new
+the current directory. Since this is commonly expected behaviour, a new
mandatory warning is now issued whenever C<do> fails to load a file which
it otherwise would have found if dot had been in C<@INC>.
=item * Script authors
If the issue is within your own code (rather than within included
-modules), then you have two main options. Firstly, if you are confident
+modules), then you have two main options. Firstly, if you are confident
that your script will only be run within a trusted directory (under which
-you expect to find trusted files and modules), then add C<.> back into the
-path; e.g.:
+you expect to find trusted files and modules), then add C<"."> back into the
+path; I<e.g.>:
BEGIN {
my $dir = "/some/trusted/directory";
On the other hand, if your script is intended to be run from within
untrusted directories (such as F</tmp>), then your script suddenly failing
-to load files may be indicative of a security issue. You most likely want
+to load files may be indicative of a security issue. You most likely want
to replace any relative paths with full paths; for example,
do ".foo_config.pl"
(export PERL_USE_UNSAFE_INC=1; \
perl Makefile.PL && make && make test && make install)
-Note that this only helps build and install an unfixed module. It's
+Note that this only helps build and install an unfixed module. It's
possible for the tests to pass (since they were run under
C<PERL_USE_UNSAFE_INC=1>), but for the module itself to fail to perform
-correctly in production. In this case you may have to temporarily modify
-your script until such time as fixed version of the module is released.
+correctly in production. In this case you may have to temporarily modify
+your script until such time as a fixed version of the module is released.
For example:
use Foo::Bar;
$config = Foo::Bar->read_config();
}
-This is only rarely expected to be necessary. Again, if doing this,
+This is only rarely expected to be necessary. Again, if doing this,
assess the resultant risks first.
=item * Module Authors
If you maintain a CPAN distribution, it may need updating to run in
-a dotless environment. Although C<cpan> and other such tools will
-currently set the C<PERL_USE_UNSAFE_INC> during module build, this is
-temporary workaround for the set of modules which rely on C<.> being in
-C<@INC> for installation and testing, and this may mask deeper issues. It
+a dotless environment. Although C<cpan> and other such tools will
+currently set the C<PERL_USE_UNSAFE_INC> during module build, this is a
+temporary workaround for the set of modules which rely on C<"."> being in
+C<@INC> for installation and testing, and this may mask deeper issues. It
could result in a module which passes tests and installs, but which
fails at run time.
During build, test and install, it will normally be the case that any perl
processes will be executing directly within the root directory of the
-untarred distribution, or a known subdirectory of that, such as F<t/>. It
+untarred distribution, or a known subdirectory of that, such as F<t/>. It
may well be that F<Makefile.PL> or F<t/foo.t> will attempt to include
local modules and configuration files using their direct relative
filenames, which will now fail.
This makes it likely that your existing build and test code will work, but
this may mask issues with your code which only manifest when used after
-install. It is prudent to try and run your build process with that
+install. It is prudent to try and run your build process with that
variable explicitly disabled:
+
(export PERL_USE_UNSAFE_INC=0; \
perl Makefile.PL && make && make test && make install)
This is more likely to show up any potential problems with your module's
-build process, or even with the module itself. Fixing such issues will
+build process, or even with the module itself. Fixing such issues will
ensure both that your module can again be installed manually, and that
it will still build once the C<PERL_USE_UNSAFE_INC> crutch goes away.
When fixing issues in tests due to the removal of dot from C<@INC>,
reinsertion of dot into C<@INC> should be performed with caution, for this
-too may suppress real errors in your runtime code. You are encouraged
+too may suppress real errors in your runtime code. You are encouraged
wherever possible to apply the aforementioned approaches with explicit
-absolute/relative paths, or relocate your needed files into a subdirectory
-and insert that subdirectory into C<@INC> instead.
+absolute/relative paths, or to relocate your needed files into a
+subdirectory and insert that subdirectory into C<@INC> instead.
If your runtime code has problems under the dotless C<@INC>, then the comments
-above on how to fix for script authors will mostly apply here too. Bear in
+above on how to fix for script authors will mostly apply here too. Bear in
mind though that it is considered bad form for a module to globally add dot to
C<@INC>, since it introduces both a security risk and hides issues of
accidentally requiring dot in C<@INC>, as explained above.
These have been deprecated since v5.16, with a deprecation message
raised for some uses starting in v5.22. Unfortunately, the code added
-to raise the message had bugs, and did not catch all the relevant uses
-of literal C<"{">. So, some uses failed to be warned about. Therefore,
-enforcement of this ban for these uses is deferred until Perl 5.30, and
-a deprecation message is now raised for them.
+to raise the message was buggy, and failed to warn in some cases where
+it should have. Therefore, enforcement of this ban for these cases is
+deferred until Perl 5.30, but the code has been fixed to raise a
+default-on deprecation message for them in the meantime.
Some uses of literal C<"{"> occur in contexts where we do not foresee
-the meaning be anything but the literal, such as the very first
-character in the pattern. To avoid forcing needless code changes, this
-restriction is not enforced, nor are there current plans to enforce it,
-in those areas. But is always correct to escape C<"{">, and the simple
-rule to remember is to do so.
+the meaning ever being anything but the literal, such as the very first
+character in the pattern, or after a C<"|"> meaning alternation. Thus
+
+ qr/{fee|{fie/
+
+matches either of the strings C<{fee> or C<{fie>. To avoid forcing
+unnecessary code changes, these uses do not need to be escaped, and no
+warning is raised about them, and there are no current plans to change this.
+
+But it is always correct to escape C<"{">, and the simple rule to
+remember is to always do so.
=head2 C<scalar(%hash)> return signature changed
the buckets allocated in the hash. It will simply return the count of used
keys. It is thus equivalent to C<0+keys(%hash)>.
-A form of backwards compatibility is provided via C<Hash::Util::bucket_ratio()>
-which provides the same behavior as C<scalar(%hash)> provided prior to Perl
-5.25.
+A form of backwards compatibility is provided via
+L<C<Hash::Util::bucket_ratio()>|Hash::Util/bucket_ratio> which provides
+the same behavior as
+C<scalar(%hash)> provided in Perl 5.24 and earlier.
=head2 C<keys> returned from an lvalue subroutine
=head2 POSIX::tmpnam() has been removed
The fundamentally unsafe C<tmpnam()> interface was deprecated in
-Perl 5.22.0 and has now been removed. In its place you can use,
+Perl 5.22 and has now been removed. In its place you can use,
for example, the L<File::Temp> interfaces.
=head2 require ::Foo::Bar is now illegal.
-Formerly, C<require ::Foo::Bar> would try to read F</Foo/Bar.pm>. Now any
+Formerly, C<require ::Foo::Bar> would try to read F</Foo/Bar.pm>. Now any
bareword require which starts with a double colon dies instead.
=head2 Literal control character variable names are no longer permissible
=head2 C<NBSP> is no longer permissible in C<\N{...}>
The name of a character may no longer contain non-breaking spaces. It
-has been deprecated to do so since Perl v5.22.
+has been deprecated to do so since Perl 5.22.
=head1 Deprecations
In order for Perl to eventually allow string delimiters to be Unicode
grapheme clusters (which look like a single character, but may be
-a sequence of several ones), we have to stop allowing a single char
+a sequence of several ones), we have to stop allowing a single character
delimiter that isn't a grapheme by itself. These are unlikely to exist
in actual code, as they would typically display as attached to the
character in front of them.
+=head2 C<\cI<X>> that maps to a printable is no longer deprecated
+
+This means we have no plans to remove this feature. It still raises a
+warning, but only if syntax warnings are enabled. The feature was
+originally intended to be a way to express non-printable characters that
+don't have a mnemonic (C<\t> and C<\n> are mnemonics for two
+non-printable characters, but most non-printables don't have a
+mnemonic.) But the feature can be used to specify a few printable
+characters, though those are more clearly expressed as the printable
+itself. See
+L<http://www.nntp.perl.org/group/perl.perl5.porters/2017/02/msg242944.html>.
+
=head1 Performance Enhancements
=over 4
=item *
-A hash in boolean context is now sometimes faster, e.g.
+A hash in boolean context is now sometimes faster, I<e.g.>
if (!%h) { ... }
-This was already special-cased, but some cases were missed, and even the
-ones which weren't have been improved.
-
-=item *
-
-Several other ops may now also be faster in boolean context.
+This was already special-cased, but some cases were missed (such as
+C<grep %$_, @AoH>, and even the ones which weren't have been improved.
=item * New Faster Hash Function on 64 bit builds
-We use a different hash function for short and long keys. This should
+We use a different hash function for short and long keys. This should
improve performance and security, especially for long keys.
=item * readline is faster
=item *
-Array and hash assignment are now faster, e.g.
+Array and hash assignment are now faster, I<e.g.>
(..., @a) = (...);
(..., %h) = (...);
=item *
-Clearing hashes and arrays has been made slightly faster. Now code
-like this is around 5% faster:
+Better optimise array and hash assignment: where an array or hash appears
+in the LHS of a list assignment, such as C<(..., @a) = (...);>, it's
+likely to be considerably faster, especially if it involves emptying the
+array/hash. For example this code runs about 1/3 faster compared to
+5.24.0:
my @a;
- for my $i (1..3_000_000) {
+ for my $i (1..10_000_000) {
@a = (1,2,3);
@a = ();
}
-and this code around 3% faster:
-
- my %h;
- for my $i (1..3_000_000) {
- %h = qw(a 1 b 2);
- %h = ();
- }
-
-=item *
-
-Better optimise array and hash assignment
=item *
=item *
The internal op implementing the C<split> builtin has been simplified and
-sped up. Firstly, it no longer requires a subsidiary internal C<pushre> op
-to do its work. Secondly, code of the form C<my @x = split(...)> is now
+sped up.
Firstly, it no longer requires a subsidiary internal C<pushre> op
+to do its work. Secondly, code of the form C<my @x = split(...)> is now
optimised in the same way as C<@x = split(...)>, and is therefore a few
percent faster.
=item *
Bareword constant strings are now permitted to take part in constant
-folding. They were originally exempted from constant folding in August 1999,
+folding. They were originally exempted from constant folding in August 1999,
during the development of Perl 5.6, to ensure that C<use strict "subs">
-would still apply to bareword constants. That has now been accomplished a
+would still apply to bareword constants. That has now been accomplished a
different way, so barewords, like other constants, now gain the performance
benefits of constant folding.
L<attributes> has been upgraded from version 0.27 to 0.29.
The deprecation message for the C<:unique> and C<:locked> attributes
-now mention they will disappear in Perl 5.28.
+now mention that they will disappear in Perl 5.28.
=item *
Avoid stderr noise in tests
-Check for echo in new Net::Ping tests.
+Check for echo in new L<Net::Ping> tests.
=item *
=item *
-L<POSIX> has been upgraded from version 1.65 to 1.76. This remedies several
+L<POSIX> has been upgraded from version 1.65 to 1.76. This remedies several
defects in making its symbols exportable. [perl #127821]
The C<POSIX::tmpnam()> interface has been removed,
see L</"POSIX::tmpnam() has been removed">.
regular expression pattern modifier, and a change to the L<S<C<use re
'strict'>>|re/'strict' mode> experimental feature. When S<C<re
'strict'>> is enabled, a warning now will be generated for all
-unescaped uses of the two characters C<}> and C<]> in regular
+unescaped uses of the two characters C<"}"> and C<"]"> in regular
expression patterns (outside bracketed character classes) that are taken
-literally. This brings them more in line with the C<)> character which
+literally. This brings them more in line with the C<")"> character which
is always a metacharacter unless escaped. Being a metacharacter only
sometimes, depending on action at a distance, can lead to silently
having the pattern mean something quite different than was intended,
=head3 L<perldeprecation>
This file documents all upcoming deprecations, and some of the deprecations
-which already have been removed. The purpose of this documentation is
+which already have been removed. The purpose of this documentation is
two-fold: document what will disappear, and by which version, and serve
as a guide for people dealing with code which has features that no longer
work after an upgrade of their perl.
=head2 Changes to Existing Documentation
-=head3 L<perlcall>
-
-=over 4
+We have attempted to update the documentation to reflect the changes
+listed in this document. If you find any we have missed, send email to
+L<mailto:perlbug@perl.org>.
-=item *
+Additionally all references to Usenet have been removed, and the
+following selected changes have been made:
-Use of unassigned code point or non-standalone grapheme for a delimiter will be a fatal error starting in Perl 5.30
+=head3 L<perlfunc>
-This was changed to drop a leading C<v> in C<v5.30>, so it uses the same
-style as other deprecation messages.
+=over 4
=item *
-"\c%c" is more clearly written simply as "%s".
-
-It was decided to undeprecate the use of C<\c%c>, see L<http://www.nntp.perl.org/group/perl.perl5.porters/2017/02/msg242944.html>
+Removed obsolete text about L<C<defined()>|perlfunc/defined>
+on aggregates that should have been deleted earlier, when the feature
+was removed.
=item *
-Removed redundant C<dSP> from an example.
-
-=back
-
-=head3 L<perlcommunity>
-
-=over 4
+Corrected documentation of L<C<eval()>|perlfunc/eval>,
+and L<C<evalbytes()>|perlfunc/evalbytes>.
=item *
-All references to Usenet have been removed.
-
-=back
-
-=head3 L<perldata>
-
-=over 4
+Clarified documentation of L<C<seek()>|perlfunc/seek>,
+L<C<tell()>|perlfunc/tell> and L<C<sysseek()>|perlfunc/sysseek>
+regarding that positions are in bytes vs. characters.
+L<[perl #128607]|https://rt.perl.org/Public/Bug/Display.html?id=128607>
=item *
-Updated documentation of C<scalar(%hash)>. See L</scalar(%hash) return
-signature changed> above.
+Clarified documentation of L<C<sort()>|perlfunc/sort LIST> concerning
+the variables C<$a> and C<$b>.
=item *
-Use of single character variables, with the variable name a non printable
-character in the range C<\x80>-C<\xFF> is no longer allowed. Update the docs to
-reflect this.
-
-=back
-
-=head3 L<perldelta>
-
-=over 4
+In L<C<split()>|perlfunc/split> added a caution about its use in Perls
+before 5.11, and noted that certain pattern modifiers are legal in it.
=item *
-All references to Usenet have been removed.
-
-=back
-
-=head3 L<perldiag>
-
-=over 4
+Removed obsolete documentation of L<C<study()>|perlfunc/study>, noting
+that it is now a no-op.
=item *
-Deprecations are to be marked with a D.
-C<"%s() is deprecated on :utf8 handles"> use a deprecation message, and as
-such, such be marked C<"(D deprecated)"> and not C<"(W deprecated)">.
+Noted that L<C<vec()>|perlfunc/vec> doesn't work well when the string
+contains characters whose code points are above 255.
=back
-=head3 L<perlexperiment>
+=head3 L<perlguts>
=over 4
=item *
-Documented new feature: See L</Declaring a reference to a variable> above.
+Added advice on
+L<formatted printing of operands of C<Size_t> and C<SSize_t>|perlguts/Formatted Printing of Size_t and SSize_t>
=back
-=head3 L<perlfunc>
+=head3 L<perlhack>
=over 4
=item *
-Defined on aggregates is no longer allowed. Perlfunc was still reporting it as
-deprecated, and that it will be deleted in the future.
-
-=item *
-
-Clarified documentation of L<C<seek()>|perlfunc/seek>,
-L<C<tell()>|perlfunc/tell> and L<C<sysseek()>|perlfunc/sysseek>.
-L<[perl #128607]|https://rt.perl.org/Public/Bug/Display.html?id=128607>
-
-=item *
-
-Removed obsolete documentation of L<C<study()>|perlfunc/study>.
+Clariy indentation rules, and note that we are migrating away from using
+tabs to indent, replacing them with sequences of SPACE characters.
=back
-=head3 L<perlguts>
+=head3 L<perlhacktips>
=over 4
=item *
-Add C<pTHX_> to magic method examples.
-
-=back
-
-=head3 L<perlhack>
-
-=over 4
+Give another reason to use C<cBOOL> to cast an expression to boolean.
=item *
-Document Tab VS Space.
+Note that there are macros C<TRUE> and C<FALSE> available to express
+boolean values.
=back
=item *
-Document C<NUL> collation handling.
-
-=item *
-
-Some locales aren't compatible with Perl. Note the potential bad
-consequences of using them.
+Some locales aren't compatible with Perl. Note that these can cause
+core dumps.
=back
=item *
-All references to Usenet have been removed.
+Various clarifications have been added.
=back
=item *
-Updated the mirror list.
-
-=item *
-
-All references to Usenet have been removed.
-
-=back
-
-=head3 L<perlnewmod>
-
-=over 4
-
-=item *
-
-All references to Usenet have been removed.
+Updated the site mirror list.
=back
=item *
-Tidy the document.
-
-=item *
-
Mention C<Moo> more.
=back
=item *
-Clarify behavior single quote regexps.
+Clarify behavior of single quote regexps.
=back
=item *
-Several minor enhancements to the documentation.
-
-=back
+The first part was extensively rewritten to incorporate various basic
+points, that in earlier versions were mentioned in sort of an appendix
+on Version 8 regular expressions.
-=head3 L<perlsec>
-
-=over 4
-
-=item *
-
-Fixed link to Crosby paper on hash complexity attack.
+Note that it is common to have the C</x> modifier and forget that this
+means that C<"#"> has to be escaped.
=back
-=head3 L<perlref>
+=head3 L<perlretut>
=over 4
=item *
-Documented new feature: See L</Declaring a reference to a variable> above.
-
-=back
-
-=head3 L<perltie>
-
-=over 4
+Add introductory material
=item *
-Updated documentation of C<scalar(%hash)>. See L</scalar(%hash) return
-signature changed> above.
+Note that a metacharacter occurring in a context where it can't mean
+that, silently loses its meta-ness and matches literally.
+L<C<use re 'strict'>|re/'strict' mode> can catch some of these.
=back
=item *
-Documented change to C<\p{I<script>}> to now use the improved Script_Extensions
-property. See L</Use of \p{script} uses the improved Script_Extensions
-property> above.
+Corrected the text about Unicode BYTE ORDER MARK handling.
=item *
=item *
-Removed obsolete documentation of C<${^ENCODING}>. See L</${^ENCODING} has
-been removed> above.
-
-=item *
-
-Document C<@ISA>. Was documented other places, not not in L<perlvar>.
+Document C<@ISA>. Was documented other places, not not in L<perlvar>.
=back
=item *
-Since C<.> is now removed from C<@INC> by default, C<do> will now trigger
+Since C<"."> is now removed from C<@INC> by default, C<do> will now trigger
a warning recommending to fix the C<do> statement:
L<do "%s" failed, '.' is no longer in @INC|perldiag/do "%s" failed, '.' is no longer in @INC; did you mean do ".E<sol>%s"?>
Using the empty pattern (which re-executes the last successfully-matched
pattern) inside a code block in another regex, as in C</(?{ s!!new! })/>, has
-always previously yielded a segfault. It now produces an error:
+always previously yielded a segfault. It now produces an error:
L<Infinite recursion in regex|perldiag/"Infinite recursion in regex">.
=item *
L<Version control conflict marker|perldiag/"Version control conflict marker">
(F) The parser found a line starting with C<E<lt>E<lt>E<lt>E<lt>E<lt>E<lt>E<lt>>,
-C<E<gt>E<gt>E<gt>E<gt>E<gt>E<gt>E<gt>>, or C<=======>. These may be left by a
+C<E<gt>E<gt>E<gt>E<gt>E<gt>E<gt>E<gt>>, or C<=======>. These may be left by a
version control system to mark conflicts after a failed merge operation.
=item *
=item *
-L<Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by S<E<lt>-- HERE> in mE<sol>%sE<sol>|perldiag/"Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by S<<-- HERE> in m/%s/">
+L<Unescaped left brace in regex is illegal here|perldiag/Unescaped left brace in regex is illegal here in regex; marked by S<E<lt>-- HERE> in mE<sol>%sE<sol>>
-Unescaped left braces are already illegal in some contexts in regular
-expression patterns, but, due to an oversight, no deprecation warning
-was raised in other contexts where they are intended to become illegal.
-This warning is now raised in these contexts.
+Unescaped left braces are now illegal in some contexts in regular expression
+patterns. In other contexts, they are still just deprecated; they will
+be illegal in Perl 5.30.
=item *
L<C<${^ENCODING}> is no longer supported. Its use will be fatal in Perl 5.28|perldiag/"${^ENCODING} is no longer supported. Its use will be fatal in Perl 5.28">
-(D deprecated) The special variable C<${^ENCODING}>, formerly used to implement
-the C<encoding> pragma, is no longer supported as of Perl 5.26.0.
+The special variable C<${^ENCODING}>, formerly used to implement
+the C<encoding> pragma, is no longer supported as of Perl 5.26.
=item *
-Since C<.> is now removed from C<@INC> by default, C<do> will now trigger
+Since C<"."> is now removed from C<@INC> by default, C<do> will now trigger
a warning recommending to fix the C<do> statement:
L<do "%s" failed, '.' is no longer in @INC|perldiag/do "%s" failed, '.' is no longer in @INC; did you mean do ".E<sol>%s"?>
=item *
-L<Unescaped left brace in regex is illegal here in regex; marked by S<E<lt>-- HERE> in mE<sol>%sE<sol>|perldiag/"Unescaped left brace in regex is illegal here in regex; marked by S<<-- HERE> in m/%s/">
-
-The word "here" has been added to the message that was raised in
-v5.25.1. This is to indicate that there are contexts in which unescaped
-left braces are not (yet) illegal.
-
-=item *
-
Code like C<$x = $x . "a"> was incorrectly failing to yield a
L<use of uninitialized value|perldiag/"Use of uninitialized value%s">
warning when C<$x> was a lexical variable with an undefined value. That has
=item *
C<undef *_; shift> or C<undef *_; pop> inside a subroutine, with no
-argument to C<shift> or C<pop>, began crashing in Perl 5.14.0, but has now
+argument to C<shift> or C<pop>, began crashing in Perl 5.14, but has now
been fixed.
=item *
=item *
C<do> or C<require> with a reference or typeglob which, when stringified,
-contains a null character started crashing in Perl 5.20.0, but has now been
+contains a null character started crashing in Perl 5.20, but has now been
fixed. [perl #128182]
=back
=item *
-Replace obscure character range with \w.
+Replace obscure character range with C<\w>.
=back
well within the 1000-character limit imposed by SMTP mail transfer agents.
This is particularly likely to be important for the list of arguments to
C<Configure>, which can readily exceed the limit if, for example, it names
-several non-default installation paths. This change also adds the first unit
+several non-default installation paths. This change also adds the first unit
tests for perlbug. [perl #128020]
=back
Since 5.18 for testing purposes we have included support for
building perl with a variety of non-standard, and non-recommended
-hash functions. Since we do not recommend the use of these functions
-we have removed them and their corresponding build options. Specifically
+hash functions. Since we do not recommend the use of these functions
+we have removed them and their corresponding build options. Specifically
this includes the following build options:
PERL_HASH_FUNC_SDBM
Previously, two progress messages were emitted for each manpage: one by
installman itself, and one by the function in install_lib.pl that it calls to
-actually install the file. Disabling the second of those in each case saves
+actually install the file. Disabling the second of those in each case saves
over 750 lines of unhelpful output.
=item *
When building with GCC 6 and link-time optimization (the C<-flto> option to
C<gcc>), C<Configure> was treating all probed symbols as present on the
-system, regardless of whether they actually exist. This has been fixed.
+system, regardless of whether they actually exist. This has been fixed.
[perl #128131]
=item *
The F<t/test.pl> library is used for internal testing of Perl itself, and
-also copied by several CPAN modules. Some of those modules must work on
+also copied by several CPAN modules. Some of those modules must work on
older versions of Perl, so F<t/test.pl> must in turn avoid newer Perl
-features. Compatibility with Perl 5.8 was inadvertently removed some time
+features. Compatibility with Perl 5.8 was inadvertently removed some time
ago; it has now been restored. [perl #128052]
=item *
=head1 Testing
+Tests were added and changed to reflect the other additions and changes
+in this release. In addition, these substantive changes were made:
+
=over 4
=item *
-F<XS-APItest/t/utf8.t>: Several small fixes and enhancements.
+A new test script, F<comp/parser_run.t>, has been added to test
+reads through invalid pointers.
=item *
Some parts of the test suite that try to exhaustively test edge cases in the
regex implementation have been restricted to running for a maximum of five
-minutes. On slow systems they could otherwise take several hours, without
+minutes. On slow systems they could otherwise take several hours, without
significantly improving our understanding of the correctness of the code
under test.
=item *
+A new test script, F<t/re/keep_tabs.t> has been added to contain tests
+where C<\t> characters should not be expanded into spaces.
+
+=item *
+
A new test script, F<t/re/anyof.t>, has been added to test that the ANYOF nodes
generated by bracketed character classes are as expected.
=item *
+There is now more extensive testing of the Unicode-related API macros
+and functions.
+
+=item *
+
+Several of the longer running API test files have been split into
+multiple test files so that they can be run in parallel.
+
+=item *
+
F<t/harness> now tries really hard not to run tests outside of the Perl
source tree. [perl #124050]
=item OS X
-OS X El Capitan doesn't implement the clock_gettime() or clock_getres() APIs,
+OS X El Capitan doesn't implement the clock_gettime() or clock_getres() APIs;
emulate them as necessary.
=item macOS
=item VAX
-VAX floating point formats are now supported.
+VAX floating point formats are now supported on NetBSD.
=item VMS
=item *
The path separator for the C<PERL5LIB> and C<PERLLIB> environment entries is
-now a colon (C<:>) when running under a Unix shell. There is no change when
-running under DCL (it's still C<|>).
-
-=item *
-
-Remove some VMS-specific hacks from C<showlex.t>. These were added 15 years
-ago, and are no longer necessary for any VMS version now supported.
+now a colon (C<":">) when running under a Unix shell. There is no change when
+running under DCL (it's still C<"|">).
=item *
-Move C<_pDEPTH> and C<_aDEPTH> after F<config.h> otherwise DEBUGGING
-may not be defined yet.
-
-=item *
-
-VAXC has not been a possibility for a good long while, and the versions of the
-DEC/Compaq/HP/VSI C compiler that report themselves as "DEC" in a listing file
-are 15 years or more out-of-date and can be safely desupported.
+C<configure.com> now recognizes the VSI-branded C compiler and no longer
+recognizes the "DEC"-branded C compiler (as there hasn't been such a thing for
+15 or more years).
=back
attempt to fix the bug again in a way that is compatible with VS2015.
These changes do not affect compilation with GCC or with Visual Studio versions
-up to and including VS2013, i.e. the bug fix is retained (unchanged) for those
+up to and including VS2013, I<i.e.>, the bug fix is retained (unchanged) for those
compilers.
Note that you may experience compatibility problems if you mix a perl built
perl built with VS2015 with XS modules built with GCC or VS E<lt>= VS2013.
Some incompatibility may arise because of the bug fix that has been reverted
for VS2015 builds of perl, but there may well be incompatibility anyway because
-of the rewritten CRT in VS2015 (e.g. see discussion at
+of the rewritten CRT in VS2015 (I<e.g.>, see discussion at
http://stackoverflow.com/questions/30412951).
=back
=item *
-Tweaks for Win32 VC vs GCC detection makefile code. This fixes issue that CCHOME
+Tweaks for Win32 VC vs GCC detection makefile code. This fixes issue that CCHOME
depends on CCTYPE, which in auto detect mode is set after CCHOME, so CCHOME uses
-the uninit CCTYPE var. Also fix else vs .ELSE in makefile.mk
+the uninit CCTYPE var. Also fix else vs .ELSE in makefile.mk
=item *
=back
-=item VMS And Win32
-
-Fix some breakage, add 'undef' value for default_inc_excludes_dot in build
-scripts.
-
=item Linux
Drop support for Linux a.out Linux has used ELF for over twenty years.
=item *
-The C<op_class()> API function has been added. This is like the existing
-C<OP_CLASS()> macro, but can more accurately determine what struct an op
-has been allocated as. For example C<OP_CLASS()> might return
-C<OA_BASEOP_OR_UNOP> indicating that ops of this type are usually
-allocated as an C<OP> or C<UNOP>; while C<op_class()> will return
-C<OPclass_BASEOP> or C<OPclass_UNOP> as appropriate.
+A new API function C<sv_setvpv_bufsize()> allows simultaneously setting the
+length and allocated size of the buffer in an C<SV>, growing the buffer if
+necessary.
=item *
-The output format of the C<op_dump()> function (as used by C<perl -Dx>)
-has changed: it now displays an "ASCII-art" tree structure, and shows more
-low-level details about each op, such as its address and class.
+A new API macro C<SvPVCLEAR()> sets its C<SV> argument to an empty string,
+like Perl-space C<$x = ''>, but with several optimisations.
+
+=item *
+
+Several new macros and functions for dealing with Unicode and
+UTF-8-encoded strings have been added to the API, as well some changes in
+functionality of existing functions (see L<perlapi/Unicode Support> for
+more details):
+
+=over
=item *
=item *
Calling macros like C<isALPHA_utf8> on malformed UTF-8 have issued a
-deprecation warning since Perl v5.18. They now die.
+deprecation warning since Perl 5.18. They now die.
Similarly, macros like C<toLOWER_utf8> on malformed UTF-8 now die.
=item *
-Calling the functions C<utf8n_to_uvchr> and its derivatives, while
-passing a string length of 0 is now asserted against in DEBUGGING
-builds, and otherwise returns the Unicode REPLACEMENT CHARACTER. If
-you have nothing to decode, you shouldn't call the decode function.
+Several new macros for analysing the validity of utf8 sequences. These
+are:
+
+C<L<perlapi/UTF8_GOT_ABOVE_31_BIT>>
+C<L<perlapi/UTF8_GOT_CONTINUATION>>
+C<L<perlapi/UTF8_GOT_EMPTY>>
+C<L<perlapi/UTF8_GOT_LONG>>
+C<L<perlapi/UTF8_GOT_NONCHAR>>
+C<L<perlapi/UTF8_GOT_NON_CONTINUATION>>
+C<L<perlapi/UTF8_GOT_OVERFLOW>>
+C<L<perlapi/UTF8_GOT_SHORT>>
+C<L<perlapi/UTF8_GOT_SUPER>>
+C<L<perlapi/UTF8_GOT_SURROGATE>>
+C<L<perlapi/UTF8_IS_INVARIANT>>
+C<L<perlapi/UTF8_IS_NONCHAR>>
+C<L<perlapi/UTF8_IS_SUPER>>
+C<L<perlapi/UTF8_IS_SURROGATE>>
+C<L<perlapi/UVCHR_IS_INVARIANT>>
+C<L<perlapi/isUTF8_CHAR_flags>>
+C<L<perlapi/isSTRICT_UTF8_CHAR>>
+C<L<perlapi/isC9_STRICT_UTF8_CHAR>>
=item *
-The functions C<utf8n_to_uvchr> and its derivatives now return the
-Unicode REPLACEMENT CHARACTER if called with UTF-8 that has the overlong
-malformation, and that malformation is allowed by the input parameters.
-This malformation is where the UTF-8 looks valid syntactically, but
-there is a shorter sequence that yields the same code point. This has
-been forbidden since Unicode version 3.1.
+Functions that are all extensions of the C<is_utf8_string_*()> functions,
+that apply various restrictions to the UTF-8 recognized as valid:
+
+C<L<perlapi/is_strict_utf8_string>>,
+C<L<perlapi/is_strict_utf8_string_loc>>,
+C<L<perlapi/is_strict_utf8_string_loclen>>,
+
+C<L<perlapi/is_c9strict_utf8_string>>,
+C<L<perlapi/is_c9strict_utf8_string_loc>>,
+C<L<perlapi/is_c9strict_utf8_string_loclen>>,
+
+C<L<perlapi/is_utf8_string_flags>>,
+C<L<perlapi/is_utf8_string_loc_flags>>,
+C<L<perlapi/is_utf8_string_loclen_flags>>,
+
+C<L<perlapi/is_utf8_fixed_width_buf_flags>>,
+C<L<perlapi/is_utf8_fixed_width_buf_loc_flags>>,
+C<L<perlapi/is_utf8_fixed_width_buf_loclen_flags>>.
+
+C<L<perlapi/is_utf8_invariant_string>>.
+C<L<perlapi/is_utf8_valid_partial_char>>.
+C<L<perlapi/is_utf8_valid_partial_char_flags>>.
=item *
-The functions C<utf8n_to_uvchr> and its derivatives now accept an input
+The functions C<L<perlapi/utf8n_to_uvchr>> and its derivatives have had
+several changes of behaviour.
+
+Calling them, while passing a string length of 0 is now asserted against
+in DEBUGGING builds, and otherwise returns the Unicode REPLACEMENT
+CHARACTER. If you have nothing to decode, you shouldn't call the decode
+function.
+
+They now return the Unicode REPLACEMENT CHARACTER if called with UTF-8
+that has the overlong malformation, and that malformation is allowed by
+the input parameters. This malformation is where the UTF-8 looks valid
+syntactically, but there is a shorter sequence that yields the same code
+point. This has been forbidden since Unicode version 3.1.
+
+They now accept an input
flag to allow the overflow malformation. This malformation is when the
UTF-8 may be syntactically valid, but the code point it represents is
not capable of being represented in the word length on the platform.
but it returns the Unicode REPLACEMENT CHARACTER as the value of the
code point (since the real value is not representable).
-=item *
-
-The C<PADOFFSET> type has changed from being unsigned to signed, and
-several pad-related variables such as C<PL_padix> have changed from being
-of type C<I32> to type C<PADOFFSET>.
-
-=item *
-
-The function C<L<perlapi/utf8n_to_uvchr>> has been changed to not
+C<utf8n_to_uvchr> has been changed to not
abandon searching for other malformations when the first one is
encountered. A call to it thus can generate multiple diagnostics,
instead of just one.
=item *
+C<valid_utf8_to_uvchr()> has been added to the API (although it was
+present in core earlier). Like C<utf8_to_uvchr_buf()>, but assumes that
+the next character is well-formed.
+
+=item *
+
A new function, C<L<perlapi/utf8n_to_uvchr_error>>, has been added for
use by modules that need to know the details of UTF-8 malformations
beyond pass/fail. Previously, the only ways to know why a sequence was
=item *
-Several new functions for handling Unicode have been added to the API:
-C<L<perlapi/is_strict_utf8_string>>,
-C<L<perlapi/is_c9strict_utf8_string>>,
-C<L<perlapi/is_utf8_string_flags>>,
-C<L<perlapi/is_strict_utf8_string_loc>>,
-C<L<perlapi/is_strict_utf8_string_loclen>>,
-C<L<perlapi/is_c9strict_utf8_string_loc>>,
-C<L<perlapi/is_c9strict_utf8_string_loclen>>,
-C<L<perlapi/is_utf8_string_loc_flags>>,
-C<L<perlapi/is_utf8_string_loclen_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_loc_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_loclen_flags>>.
-
-These functions are all extensions of the C<is_utf8_string_*()> functions,
-that apply various restrictions to the UTF-8 recognized as valid.
+There is now a safer version of utf8_hop(), called utf8_hop_safe().
+Unlike utf8_hop(), utf8_hop_safe() won't navigate before the beginning or
+after the end of the supplied buffer.
=item *
-A new API function C<sv_setvpv_bufsize()> allows simultaneously setting the
-length and allocated size of the buffer in an C<SV>, growing the buffer if
-necessary.
+Two new functions, C<utf8_hop_forward()> and C<utf8_hop_back()> are
+similar to C<utf8_hop_safe()> but are for when you know which direction
+you wish to travel.
=item *
-A new API macro C<SvPVCLEAR()> sets its C<SV> argument to an empty string,
-like Perl-space C<$x = ''>, but with several optimisations.
+Two new macros which return useful utf8 byte sequences:
-=item *
+C<L<perlapi/BOM_UTF8>>
+C<L<perlapi/REPLACEMENT_CHARACTER_UTF8>>
-All parts of the internals now agree that the C<sassign> op is a C<BINOP>;
-previously it was listed as a C<BASEOP> in F<regen/opcodes>, which meant
-that several parts of the internals had to be special-cased to accommodate
-it. This oddity's original motivation was to handle code like C<$x ||= 1>;
-that is now handled in a simpler way.
+=back
=item *
-Several new internal C macros have been added that take a string literal as
-arguments, alongside existing routines that take the equivalent value as two
-arguments, a character pointer and a length. The advantage of this is that
-the length of the string is calculated automatically, rather than having to
-be done manually. These routines are now used where appropriate across the
-entire codebase.
-
-=item *
+Perl is now built with the C<PERL_OP_PARENT> compiler define enabled by
+default. To disable it, use the C<PERL_NO_OP_PARENT> compiler define.
+This flag alters how the C<op_sibling> field is used in C<OP> structures,
+and has been available optionally since perl 5.22.
-The code in F<gv.c> that determines whether a variable has a special meaning
-to Perl has been simplified.
+See L<perl5220delta/"Internal Changes"> for more details of what this
+build option does.
=item *
-The C<DEBUGGING>-mode output for regex compilation and execution has been
-enhanced.
+Three new ops, C<OP_ARGELEM>, C<OP_ARGDEFELEM> and C<OP_ARGCHECK> have
+been added. These are intended principally to implement the individual
+elements of a subroutine signature, plus any overall checking required.
=item *
-Several macros and functions have been added to the public API for
-dealing with Unicode and UTF-8-encoded strings. See
-L<perlapi/Unicode Support>.
+The C<op_class()> API function has been added. This is like the existing
+C<OP_CLASS()> macro, but can more accurately determine what struct an op
+has been allocated as. For example C<OP_CLASS()> might return
+C<OA_BASEOP_OR_UNOP> indicating that ops of this type are usually
+allocated as an C<OP> or C<UNOP>; while C<op_class()> will return
+C<OPclass_BASEOP> or C<OPclass_UNOP> as appropriate.
=item *
-Use C<my_strlcat()> in C<locale.c>. While C<strcat()> is safe in this context,
-some compilers were optimizing this to C<strcpy()> causing a porting test to
-fail that looks for unsafe code. Rather than fighting this, we just use
-C<my_strlcat()> instead.
+All parts of the internals now agree that the C<sassign> op is a C<BINOP>;
+previously it was listed as a C<BASEOP> in F<regen/opcodes>, which meant
+that several parts of the internals had to be special-cased to accommodate
+it. This oddity's original motivation was to handle code like C<$x ||= 1>;
+that is now handled in a simpler way.
=item *
-Three new ops, C<OP_ARGELEM>, C<OP_ARGDEFELEM> and C<OP_ARGCHECK> have
-been added. These are intended principally to implement the individual
-elements of a subroutine signature, plus any overall checking required.
+The output format of the C<op_dump()> function (as used by C<perl -Dx>)
+has changed: it now displays an "ASCII-art" tree structure, and shows more
+low-level details about each op, such as its address and class.
=item *
-Perl no longer panics when switching into some locales on machines with
-buggy C<strxfrm()> implementations in their libc. [perl #121734]
+The C<PADOFFSET> type has changed from being unsigned to signed, and
+several pad-related variables such as C<PL_padix> have changed from being
+of type C<I32> to type C<PADOFFSET>.
=item *
-Perl is now built with the C<PERL_OP_PARENT> compiler define enabled by
-default. To disable it, use the C<PERL_NO_OP_PARENT> compiler define.
-This flag alters how the C<op_sibling> field is used in C<OP> structures,
-and has been available optionally since perl 5.22.0.
-
-See L<perl5220delta/"Internal Changes"> for more details of what this
-build option does.
+The C<DEBUGGING>-mode output for regex compilation and execution has been
+enhanced.
=item *
-The meanings of some internal SV flags have been changed
-
-OPpRUNTIME, SVpbm_VALID, SVpbm_TAIL, SvTAIL_on, SvTAIL_off, SVrepl_EVAL,
-SvEVALED
+Several obscure SV flags have been eliminated, sometimes along with the
+macros which manipulate them: C<SVpbm_VALID>, C<SVpbm_TAIL>, C<SvTAIL_on>,
+C<SvTAIL_off>, C<SVrepl_EVAL>, C<SvEVALED>
=item *
-Change C<hv_fetch(…, "…", …, …)> to C<hv_fetchs(…, "…", …)>
-
-The dual-life dists all use Devel::PPPort, so they can use this function even
-though it was only added in 5.10.
+An OP op_private flag has been eliminated: C<OPpRUNTIME>. This used to
+often get set on C<PMOP>s, but had become meaningless over time.
=back
=item *
+Perl no longer panics when switching into some locales on machines with
+buggy C<strxfrm()> implementations in their libc. [perl #121734]
+
+=item *
+
C< $-{$name} > would leak an C<AV> on each access if the regular
expression had no named captures. The same applies to access to any
hash tied with L<Tie::Hash::NamedCapture> and C<< all =E<gt> 1 >>. [perl
=item *
-Since 5.24.0 in some obscure cases, a regex which included code blocks
-from multiple sources (e.g. via embedded via qr// objects) could end up
+Since 5.24 in some obscure cases, a regex which included code blocks
+from multiple sources (I<e.g.>, via embedded via qr// objects) could end up
with the wrong current pad and crash or give weird results. [perl #129881]
=item *
=item *
-Perl 5.25.9 was fixed so that under C<use utf8>, the entire Perl program
-is checked that the UTF-8 is wellformed. It turns out that several edge
-cases were missed, and are now fixed. [perl #126310] was the original
-ticket.
-
-=item *
-
Under C<use utf8>, the entire Perl program is now checked that the UTF-8
is wellformed. This resolves [perl #126310].
=item *
-The range operator C<..> on strings now handles its arguments correctly when in
+The range operator C<".."> on strings now handles its arguments correctly when in
the scope of the L<< C<unicode_strings>|feature/"The 'unicode_strings' feature" >>
-feature. The previous behaviour was sufficiently unexpected that we believe no
+feature. The previous behaviour was sufficiently unexpected that we believe no
correct program could have made use of it.
=item *
=item *
-Using a large code point with the C<W> pack template character with
+Using a large code point with the C<"W"> pack template character with
the current output position aligned at just the right point could
cause a write a single zero byte immediately beyond the end of an
allocated buffer. [perl #129149]
=item *
-Only warn once per literal about a misplaced C<_>. [perl #70878].
+Only warn once per literal about a misplaced C<"_">. [perl #70878].
=item *
Properly recognize mathematical digit ranges starting at U+1D7E.
C<use re 'strict'> is supposed to warn if you use a range whose start
-and end digit aren't from the same group of 10. It didn't do that
+and end digit aren't from the same group of 10. It didn't do that
for five groups of mathematical digits starting at U+1D7E.
=item *
-A sub containing a "forward" declaration with the same name (e.g.,
+A sub containing a "forward" declaration with the same name (I<e.g.>,
C<sub c { sub c; }>) could sometimes crash or loop infinitely. [perl
#129090]
=item *
Previously, a shebang line like C<#!perl -i u> could be erroneously
-interpreted as requesting the C<-u> option. This has been fixed. [perl
+interpreted as requesting the C<-u> option. This has been fixed. [perl
#129336]
=item *
=item *
Certain regexes making use of the experimental C<regex_sets> feature could
-trigger an assertion failure. This has been fixed. [perl #129322]
+trigger an assertion failure. This has been fixed. [perl #129322]
=item *
-Invalid assignments to a reference constructor (e.g., C<\eval=time>) could
+Invalid assignments to a reference constructor (I<e.g.>, C<\eval=time>) could
sometimes crash in addition to giving a syntax error. [perl #125679]
=item *
=item *
-A sub containing with a "forward" declaration with the same name (e.g.,
+A sub containing with a "forward" declaration with the same name
+(I<e.g.>,
C<sub c { sub c; }>) could sometimes crash or loop infinitely. [perl
#129090]
=item *
-Fixed two possible use-after-free bugs in C<Perl_yylex>. C<Perl_yylex>
+Fixed two possible use-after-free bugs in C<Perl_yylex>.
C<Perl_yylex>
maintains up to two pointers into the parser buffer, one of which can
become stale under the right conditions. [perl #129069]
=item *
-The C<&.> operator (and the C<&> operator, when it treats its arguments as
+The C<&.> operator (and the C<"&"> operator, when it treats its arguments as
strings) were failing to append a trailing null byte if at least one string
was marked as utf8 internally. Many code paths (system calls, regexp
compilation) still expect there to be a null byte in the string buffer
Check C<pack_sockaddr_un()>'s return value because C<pack_sockaddr_un()>
silently truncates the supplied path if it won't fit into the C<sun_path>
-member of C<sockaddr_un>. This may change in the future, but for now
+member of C<sockaddr_un>. This may change in the future, but for now
check the path in theC<sockaddr> matches the desired path, and skip if
it doesn't. [perl #128095]
=item *
-Make sure C<PL_oldoldbufptr> is preserved in C<scan_heredoc()>. In some
+Make sure C<PL_oldoldbufptr> is preserved in C<scan_heredoc()>. In some
cases this is used in building error messages. [perl #128988]
=item *
=item *
Fixed the parser error handling for an 'C<:attr(foo>' that does not have
-an ending 'C<)>'.
+an ending 'C<")">'.
=item *
Problems with in-place array sorts: code like C<@a = sort { ... } @a>,
where the source and destination of the sort are the same plain array, are
-optimised to do less copying around. Two side-effects of this optimisation
+optimised to do less copying around. Two side-effects of this optimisation
were that the contents of C<@a> as visible to to sort routine were
partially sorted, and under some circumstances accessing C<@a> during the
-sort could crash the interpreter. Both these issues have been fixed, and
+sort could crash the interpreter. Both these issues have been fixed, and
Sort functions see the original value of C<@a>.
=item *
=item *
-A regression from the previous development release, 5.23.3, where
-compiling a regular expression could crash the interpreter has been
-fixed. [perl #128686].
-
-=item *
-
Use of a string delimiter whose code point is above 2**31 now works
correctly on platforms that allow this. Previously, certain characters,
due to truncation, would be confused with other delimiter characters
-with special meaning (such as C<?> in C<m?...?>), resulting
+with special meaning (such as C<"?"> in C<m?...?>), resulting
in inconsistent behaviour. Note that this is non-portable,
and is based on Perl's extension to UTF-8, and is probably not
displayable nor enterable by any editor. [perl #128738]
=item *
-C<@{x> followed by a newline where C<x> represents a control or non-ASCII
+C<@{x> followed by a newline where C<"x"> represents a control or non-ASCII
character no longer produces a garbled syntax error message or a crash.
[perl #128951]
=item *
-Vivifying a subroutine stub in a deleted stash (e.g., C<delete $My::{"Foo::"};
+Vivifying a subroutine stub in a deleted stash (I<e.g.>, C<delete $My::{"Foo::"};
\&My::Foo::foo>) no longer crashes. It had begun crashing in Perl 5.18.
L<[perl #128532]|https://rt.perl.org/Public/Bug/Display.html?id=128532>
=item *
Fixed an assertion triggered by some code that handles deprecated behavior in
-formats, e.g. in cases like this:
+formats, I<e.g.>, in cases like this:
format STDOUT =
@
=item *
Expressions containing an C<&&> or C<||> operator (or their synonyms C<and>
-and C<or>) were being compiled incorrectly in some cases. If the left-hand
+and C<or>) were being compiled incorrectly in some cases. If the left-hand
side consisted of either a negated bareword constant or a negated C<do {}>
block containing a constant expression, and the right-hand side consisted of
a negated non-foldable expression, one of the negations was effectively
-ignored. The same was true of C<if> and C<unless> statement modifiers,
-though with the left-hand and right-hand sides swapped. This long-standing
+ignored. The same was true of C<if> and C<unless> statement modifiers,
+though with the left-hand and right-hand sides swapped. This long-standing
bug has now been fixed. [perl #127952]
=item *
List assignment in list context where the LHS contained aggregates and
where there were not enough RHS elements, used to skip scalar lvalues.
Previously, C<(($a,$b,@c,$d) = (1))> in list context returned C<($a)>; now
-it returns C<($a,$b,$d)>. C<(($a,$b,$c) = (1))> is unchanged: it still
-returns C<($a,$b,$c)>. This can be seen in the following:
+it returns C<($a,$b,$d)>. C<(($a,$b,$c) = (1))> is unchanged: it still
+returns C<($a,$b,$c)>. This can be seen in the following:
sub inc { $_++ for @_ }
inc(($a,$b,@c,$d) = (10))
The basic problem is that code like this: /(?{ s!!! })/ can trigger infinite
recursion on the C stack (not the normal perl stack) when the last successful
-pattern in scope is itself. Since the C stack overflows this manifests as an
+pattern in scope is itself. Since the C stack overflows this manifests as an
untrappable error/segfault, which then kills perl.
We avoid the segfault by simply forbidding the use of the empty pattern when it
=item * L<Coro>
-L<Coro> and perl v5.22.0 were already incompatible due to a change in the perl,
+L<Coro> and perl 5.22 were already incompatible due to a change in the perl,
and the reworking on the perl context stack creates a further incompatibility.
perl5-porters has L<discussed the issue on the mailing
list|http://www.nntp.perl.org/group/perl.perl5.porters/2016/05/msg236174.html>.
=item *
-The module L<lexical::underscore> no longer works on perl v5.24.0, because perl
+The module L<lexical::underscore> no longer works on Perl 5.24, because perl
no longer has a lexical C<$_>!
=item *
-C<mod_perl> has been patched for compatibility for v5.22.0 and later but no
+C<mod_perl> has been patched for compatibility for v5.22 and later but no
release has been made. The relevant patch (and other changes) can be found in
their source code repository, L<mirrored at
GitHub|https://github.com/apache/mod_perl/commit/82827132efd3c2e25cc413c85af61bb63375da6e>.
=item *
-Fixed issues with recursive regexes. The behavior was fixed in Perl 5.24.0.
+Fixed issues with recursive regexes. The behavior was fixed in Perl 5.24.
L<[perl #126182]|https://rt.perl.org/Public/Bug/Display.html?id=126182>
=back
=head1 Obituary
Jon Portnoy (AVENJ), a prolific Perl author and admired Gentoo community
-member, has passed away on August 10, 2016. He will be remembered and
-missed by all those with which he came in contact and enriched with his
+member, has passed away on August 10, 2016. He will be remembered and
+missed by all those who he came in contact with, and enriched with his
intellect, wit, and spirit.
-It is with great sadness we also note Kip Hampton's passing.. Probably
+It is with great sadness that we also note Kip Hampton's passing. Probably
best known as the author of the Perl & XML column on XML.com, he was a
core contributor to AxKit, an XML server platform that became an Apache
-Foundation project. He was a frequent speaker in the early days at
-OSCON, and most recently at YAPC::NA in Madison. He was frequently on
+Foundation project. He was a frequent speaker in the early days at
+OSCON, and most recently at YAPC::NA in Madison. He was frequently on
irc.perl.org as `ubu`, generally in the #axkit-dahut community, the
group responsible for YAPC::NA Asheville in 2011.
approximately 230,000 lines of changes to 1,800 .pm, .t, .c and .h files.
Perl continues to flourish into its third decade thanks to a vibrant community
-of users and developers. The following people are known to have contributed the
-improvements that became Perl 5.24.1:
+of users and developers. The following people are known to have contributed the
+improvements that became Perl 5.26.0:
Aaron Crane, Abigail, Ævar Arnfjörð Bjarmason, Alex Vandiver, Andreas
König, Andreas Voegele, Andrew Fresh, Andy Lester, Aristotle Pagaltzis, Chad
Yves Orton, Zefram.
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
+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
+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
If you believe you have an unreported bug, please run the L<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 C<perl -V>,
-will be sent off to perlbug@perl.org to be analysed by the Perl porting team.
+will be sent off to C<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 see
https://perl5.git.perl.org / perl5.git / blobdiff