import perl5171delta content to perl5180delta
authorRicardo Signes <rjbs@cpan.org>
Wed, 13 Mar 2013 02:39:37 +0000 (22:39 -0400)
committerRicardo Signes <rjbs@cpan.org>
Sun, 5 May 2013 19:32:19 +0000 (15:32 -0400)
Porting/perl5180delta.pod

index 8a605d0..575e1a2 100644 (file)
@@ -18,11 +18,18 @@ XXX Any important notices here
 
 =head1 Core Enhancements
 
-XXX New core language features go here.  Summarize user-visible core language
-enhancements.  Particularly prominent performance optimisations could go
-here, but most should go in the L</Performance Enhancements> section.
+=head2 More CORE:: subs
+
+Several more built-in functions have been added as subroutines to the
+CORE:: namespace, namely, those non-overridable keywords that can be
+implemented without custom parsers: C<defined>, C<delete>, C<exists>,
+C<glob>, C<pos>, C<protoytpe>, C<scalar>, C<split>, C<study>, and C<undef>.
+
+As some of these have prototypes, C<prototype('CORE::...')> has been
+changed to not make a distinction between overridable and non-overridable
+keywords.  This is to make C<prototype('CORE::pos')> consistent with
+C<prototype(&CORE::pos)>.
 
-[ List each enhancement as a =head2 entry ]
 
 =head1 Security
 
@@ -51,6 +58,58 @@ everywhere that the grammar calls for them.
 
 [ XXX ]
 
+=head2 C</(?{})/> and C</(??{})/> have been heavily reworked
+
+The implementation of this feature has been almost completely rewritten.
+Although its main intent is to fix bugs, some behaviors, especially
+related to the scope of lexical variables, will have changed.  This is
+described more fully in the L</Selected Bug Fixes> section.
+
+=head2 C<\N{BELL}> now refers to U+1F514 instead of U+0007
+
+Unicode 6.0 reused the name "BELL" for a different code point than it
+traditionally had meant.  Since Perl v5.14, use of this name still
+referred to U+0007, but would raise a deprecation warning.  Now, "BELL"
+refers to U+1F514, and the name for U+0007 is "ALERT".  All the
+functions in L<charnames> have been correspondingly updated.
+
+=head2 Alphanumeric operators must now be separated from the closing
+delimiter of regular expressions
+
+You may no longer write something like:
+
+ m/a/and 1
+
+Instead you must write
+
+ m/a/ and 1
+
+with whitespace separating the operator from the closing delimiter of
+the regular expression.  Not having whitespace has resulted in a
+deprecation warning since Perl v5.14.0.
+
+=head2 C<require> dies for unreadable files
+
+When C<require> encounters an unreadable file, it now dies.  It used to
+ignore the file and continue searching the directories in @INC
+[perl #113422].
+
+=head2 Upgrade to the Unicode 6.2 beta
+
+Unicode 6.2 is proposing some changes that may very well break some CPAN
+modules.  The timing of this nicely coincides with Perl's being early in the
+release cycle.  This commit takes the current beta 6.2, adds the proposed
+changes that aren't yet in it, and subtracts the changes that would affect \X
+processing, as those turn out to have errors, and may have to be rethought.
+Unicode has been notified of these problems.
+
+This will allow us to gather data as to whether or not the proposed changes
+cause us problems.  These will be presented to Unicode to aid in their final
+decision as to whether or not to go forward with the changes.
+
+These changes will be replaced by the final version of Unicode 6.2 before
+5.18.0 is released.
+
 =head1 Deprecations
 
 XXX Any deprecated features, syntax, modules etc. should be listed here.  In
@@ -77,6 +136,12 @@ Filetest ops manage the stack in a fractionally more efficient manner.
 Globs used in a numeric context are now numerified directly in most cases,
 rather than being numerified via stringification.
 
+=item *
+
+The C<x> repetition operator is now folded to a single constant at compile
+time if called in scalar context with constant operands and no parentheses
+around the left operand.
+
 =back
 
 =head1 Modules and Pragmata
@@ -169,6 +234,26 @@ The return value of C<pipe> is now documented.
 
 =back
 
+=head3 L<perlfaq>
+
+=over 4
+
+=item *
+
+L<perlfaq> has been synchronized with version 5.0150040 from CPAN.
+
+=back
+
+=head3 L<perlcheat>
+
+=over 4
+
+=item *
+
+L<perlcheat> has been reorganized, and a few new sections were added.
+
+=back
+
 =head3 Diagnostics
 
 The following additions or changes have been made to diagnostic output,
@@ -211,7 +296,18 @@ XXX Changes (i.e. rewording) of diagnostic messages go here
 
 =item *
 
-XXX Describe change here
+The "Runaway prototype" warning that occurs in bizarre cases has been
+removed as being unhelpful and inconsistent.
+
+=item *
+
+The "Not a format reference" error has been removed, as the only case in
+which it could be triggered was a bug.
+
+=item *
+
+The "Unable to create sub named %s" error has been removed for the same
+reason.
 
 =back
 
@@ -331,6 +427,25 @@ guaranteed anyway in the situations where this would matter.)
 
 It should now be possible to compile Perl as C++ on VMS.
 
+=item Win32
+
+C<link> on Win32 now attempts to set C<$!> to more appropriate values
+based on the Win32 API error code. [perl #112272]
+
+Perl no longer mangles the environment block, e.g. when launching a new
+sub-process, when the environment contains non-ASCII characters. Known
+problems still remain, however, when the environment contains characters
+outside of the current ANSI codepage (e.g. see the item about Unicode in
+C<%ENV> in L<http://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/todo.pod>).
+[perl #113536]
+
+=item VMS
+
+All C header files from the top-level directory of the distribution are now
+installed on VMS, providing consistency with a long-standing practice on other
+platforms. Previously only a subset were installed, which broke non-core
+extension builds for extensions that depended on the missing include files.
+
 =back
 
 =head1 Internal Changes
@@ -367,6 +482,30 @@ overloadedness itself.
 The character-processing code has been cleaned up in places.  The changes
 should be operationally invisible.
 
+=item *
+
+The C<study> function was made a no-op in 5.16.  It was simply disabled via
+a C<return> statement; the code was left in place.  Now the code supporting
+what C<study> used to do has been removed.
+
+=item *
+
+Under threaded perls, there is no longer a separate PV allocated for every
+COP to store its package name (C<< cop->stashpv >>).  Instead, there is an
+offset (C<< cop->stashoff >>) into the new C<PL_stashpad> array, which
+holds stash pointers.
+
+=item *
+
+In the pluggable regex API, the C<regexp_engine> struct has acquired a new
+field C<op_comp>, which is currently just for perl's internal use, and
+should be initialised to NULL by other regex plugin modules.
+
+=item *
+
+A new function C<alloccoptash> has been added to the API, but is considered
+experimental.  See L<perlapi>.
+
 =back
 
 =head1 Selected Bug Fixes
@@ -495,6 +634,250 @@ A race condition used to exist around fork that could cause a signal sent to
 the parent to be handled by both parent and child. Signals are now blocked
 briefly around fork to prevent this from happening [perl #82580].
 
+=item *
+
+The implementation of code blocks in regular expressions, such as C<(?{})>
+and C<(??{})>, has been heavily reworked to eliminate a whole slew of bugs.
+The main user-visible changes are:
+
+=over 4
+
+=item *
+
+Code blocks within patterns are now parsed in the same pass as the
+surrounding code; in particular it is no longer necessary to have balanced
+braces: this now works:
+
+    /(?{  $x='{'  })/
+
+This means that this error message is longer generated:
+
+    Sequence (?{...}) not terminated or not {}-balanced in regex
+
+but a new error may be seen:
+
+    Sequence (?{...}) not terminated with ')'
+
+In addition, literal code blocks within run-time patterns are only
+compiled once, at perl compile-time:
+
+    for my $p (...) {
+        # this 'FOO' block of code is compiled once,
+       # at the same time as the surrounding 'for' loop
+        /$p{(?{FOO;})/;
+    }
+
+=item *
+
+Lexical variables are now sane as regards scope, recursion and closure
+behavior. In particular, C</A(?{B})C/> behaves (from a closure viewpoint)
+exactly like C</A/ && do { B } && /C/>, while  C<qr/A(?{B})C/> is like
+C<sub {/A/ && do { B } && /C/}>. So this code now works how you might
+expect, creating three regexes that match 0, 1, and 2:
+
+    for my $i (0..2) {
+        push @r, qr/^(??{$i})$/;
+    }
+    "1" =~ $r[1]; # matches
+
+=item *
+
+The C<use re 'eval'> pragma is now only required for code blocks defined
+at runtime; in particular in the following, the text of the C<$r> pattern is
+still interpolated into the new pattern and recompiled, but the individual
+compiled code-blocks within C<$r> are reused rather than being recompiled,
+and C<use re 'eval'> isn't needed any more:
+
+    my $r = qr/abc(?{....})def/;
+    /xyz$r/;
+
+=item *
+
+Flow control operators no longer crash. Each code block runs in a new
+dynamic scope, so C<next> etc. will not see
+any enclosing loops. C<return> returns a value
+from the code block, not from any enclosing subroutine.
+
+=item *
+
+Perl normally caches the compilation of run-time patterns, and doesn't
+recompile if the pattern hasn't changed, but this is now disabled if
+required for the correct behavior of closures. For example:
+
+    my $code = '(??{$x})';
+    for my $x (1..3) {
+       # recompile to see fresh value of $x each time
+        $x =~ /$code/;
+    }
+
+
+=item *
+
+The C</msix> and C<(?msix)> etc. flags are now propagated into the return
+value from C<(??{})>; this now works:
+
+    "AB" =~ /a(??{'b'})/i;
+
+=item *
+
+Warnings and errors will appear to come from the surrounding code (or for
+run-time code blocks, from an eval) rather than from an C<re_eval>:
+
+    use re 'eval'; $c = '(?{ warn "foo" })'; /$c/;
+    /(?{ warn "foo" })/;
+
+formerly gave:
+
+    foo at (re_eval 1) line 1.
+    foo at (re_eval 2) line 1.
+
+and now gives:
+
+    foo at (eval 1) line 1.
+    foo at /some/prog line 2.
+
+=back
+
+=item *
+
+Perl now works as well as can be expected on all releases of Unicode so
+far.  In v5.16, it worked on Unicodes 6.0 and 6.1, but there were
+various bugs for earlier releases; the older the release the more
+problems.
+
+=item *
+
+C<vec> no longer produces "uninitialized" warnings in lvalue context
+[perl #9423].
+
+=item *
+
+An optimization involving fixed strings in regular expressions could cause
+a severe performance penalty in edge cases.  This has been fixed
+[perl #76546].
+
+=item *
+
+In certain cases, including empty subpatterns within a regular expression (such
+as C<(?:)> or C<(?:|)>) could disable some optimizations. This has been fixed.
+
+=item *
+
+The "Can't find an opnumber" message that C<prototype> produces when passed
+a string like "CORE::nonexistent_keyword" now passes UTF-8 and embedded
+NULs through unchanged [perl #97478].
+
+=item *
+
+C<prototype> now treats magical variables like C<$1> the same way as
+non-magical variables when checking for the CORE:: prefix, instead of
+treating them as subroutine names.
+
+=item *
+
+Under threaded perls, a runtime code block in a regular expression could
+corrupt the package name stored in the op tree, resulting in bad reads
+in C<caller>, and possibly crashes [perl #113060].
+
+=item *
+
+Referencing a closure prototype (C<\&{$_[1]}> in an attribute handler for a
+closure) no longer results in a copy of the subroutine (or assertion
+failures on debugging builds).
+
+=item *
+
+C<eval '__PACKAGE__'> now returns the right answer on threaded builds if
+the current package has been assigned over (as in
+C<*ThisPackage:: = *ThatPackage::>) [perl #78742].
+
+=item *
+
+If a package is deleted by code that it calls, it is possible for C<caller>
+to see a stack frame belonging to that deleted package.  C<caller> could
+crash if the stash's memory address was reused for a scalar and a
+substitution was performed on the same scalar [perl #113486].
+
+=item *
+
+C<UNIVERSAL::can> no longer treats its first argument differently
+depending on whether it is a string or number internally.
+
+=item *
+
+C<open> with C<< <& >> for the mode checks to see whether the third argument is
+a number, in determining whether to treat it as a file descriptor or a handle
+name.  Magical variables like C<$1> were always failing the numeric check and
+being treated as handle names.
+
+=item *
+
+C<warn>'s handling of magical variables (C<$1>, ties) has undergone several
+fixes.  C<FETCH> is only called once now on a tied argument or a tied C<$@>
+[perl #97480].  Tied variables returning objects that stringify as "" are
+no longer ignored.  A tied C<$@> that happened to return a reference the
+I<previous> time it was used is no longer ignored.
+
+=item *
+
+C<warn ""> now treats C<$@> with a number in it the same way, regardless of
+whether it happened via C<$@=3> or C<$@="3">.  It used to ignore the
+former.  Now it appends "\t...caught", as it has always done with
+C<$@="3">.
+
+=item *
+
+Numeric operators on magical variables (e.g., S<C<$1 + 1>>) used to use
+floating point operations even where integer operations were more appropriate,
+resulting in loss of accuracy on 64-bit platforms [perl #109542].
+
+=item *
+
+Unary negation no longer treats a string as a number if the string happened
+to be used as a number at some point.  So, if C<$x> contains the string "dogs",
+C<-$x> returns "-dogs" even if C<$y=0+$x> has happened at some point.
+
+=item *
+
+In Perl 5.14, C<-'-10'> was fixed to return "10", not "+10".  But magical
+variables (C<$1>, ties) were not fixed till now [perl #57706].
+
+=item *
+
+Unary negation now treats strings consistently, regardless of the internal
+C<UTF8> flag.
+
+=item *
+
+A regression introduced in Perl v5.16.0 involving
+C<tr/I<SEARCHLIST>/I<REPLACEMENTLIST>/> has been fixed.  Only the first
+instance is supposed to be meaningful if a character appears more than
+once in C<I<SEARCHLIST>>.  Under some circumstances, the final instance
+was overriding all earlier ones.  [perl #113584]
+
+=item *
+
+Regular expressions like C<qr/\87/> previously silently inserted a NUL
+character, thus matching as if it had been written C<qr/\00087/>.  Now it
+matches as if it had been written as C<qr/87/>, with a message that the
+sequence C<"\8"> is unrecognized.
+
+=item *
+
+C<__SUB__> now works in special blocks (C<BEGIN>, C<END>, etc.).
+
+=item *
+
+Thread creation on Windows could theoretically result in a crash if done
+inside a C<BEGIN> block.  It still does not work properly, but it no longer
+crashes [perl #111610].
+
+=item *
+
+C<\&{''}> (with the empty string) now autovivifies a stub like any other
+sub name, and no longer produces the "Unable to create sub" error
+[perl #94476].
+
 =back
 
 =head1 Known Problems