Commit | Line | Data |
d4438f94 |
1 | =encoding utf8 |
2 | |
3 | =head1 NAME |
4 | |
5 | [ this is a template for a new perldelta file. Any text flagged as |
6 | XXX needs to be processed before release. ] |
7 | |
8 | perldelta - what is new for perl v5.13.1 |
9 | |
10 | =head1 DESCRIPTION |
11 | |
12 | This document describes differences between the 5.13.0 release and |
13 | the 5.13.1 release. |
14 | |
15 | If you are upgrading from an earlier release such as 5.10, first read |
16 | L<perl5120delta>, which describes differences between 5.10 and |
17 | 5.12. |
18 | |
19 | =head1 Notice |
20 | |
21 | XXX Any important notices here |
22 | |
23 | =head1 Incompatible Changes |
24 | |
df5278db |
25 | =head2 "C<\cI<X>>" |
d4438f94 |
26 | |
df5278db |
27 | The backslash-c construct was designed as a way of specifying |
28 | non-printable characters, but there were no restrictions (on ASCII |
29 | platforms) on what the character following the C<c> could be. Now, that |
30 | character must be one of the ASCII characters. |
d4438f94 |
31 | |
72ecaef9 |
32 | =head2 localised tied hashes, arrays and scalars are no longed tied |
33 | |
34 | In the following: |
35 | |
36 | tie @a, ...; |
37 | { |
38 | local @a; |
39 | # here, @a is a now a new, untied array |
40 | } |
41 | # here, @a refers again to the old, tied array |
42 | |
43 | The new local array used to be made tied too, which was fairly pointless, |
44 | and has now been fixed. This fix could however potentially cause a change |
45 | in behaviour of some code. |
46 | |
d4438f94 |
47 | =head1 Core Enhancements |
48 | |
49 | XXX New core language features go here. Summarise user-visible core language |
50 | enhancements. Particularly prominent performance optimisations could go |
51 | here, but most should go in the L</Performance Enhancements> section. |
52 | |
9d5401ce |
53 | =head2 Exception Handling Reliability |
54 | |
55 | Several changes have been made to the way C<die>, C<warn>, and C<$@> |
56 | behave, in order to make them more reliable and consistent. |
57 | |
58 | When an exception is thrown inside an C<eval>, the exception is no |
59 | longer at risk of being clobbered by code running during unwinding |
60 | (e.g., destructors). Previously, the exception was written into C<$@> |
61 | early in the throwing process, and would be overwritten if C<eval> was |
62 | used internally in the destructor for an object that had to be freed |
63 | while exiting from the outer C<eval>. Now the exception is written |
64 | into C<$@> last thing before exiting the outer C<eval>, so the code |
65 | running immediately thereafter can rely on the value in C<$@> correctly |
66 | corresponding to that C<eval>. |
67 | |
68 | Likewise, a C<local $@> inside an C<eval> will no longer clobber any |
69 | exception thrown in its scope. Previously, the restoration of C<$@> upon |
70 | unwinding would overwrite any exception being thrown. Now the exception |
71 | gets to the C<eval> anyway. So C<local $@> is safe inside an C<eval>, |
72 | albeit of rather limited use. |
73 | |
74 | Exceptions thrown from object destructors no longer modify the C<$@> |
75 | of the surrounding context. (If the surrounding context was exception |
76 | unwinding, this used to be another way to clobber the exception being |
77 | thrown. Due to the above change it no longer has that significance, |
78 | but there are other situations where C<$@> is significant.) Previously |
79 | such an exception was sometimes emitted as a warning, and then either |
80 | string-appended to the surrounding C<$@> or completely replaced the |
81 | surrounding C<$@>, depending on whether that exception and the surrounding |
82 | C<$@> were strings or objects. Now, an exception in this situation is |
83 | always emitted as a warning, leaving the surrounding C<$@> untouched. |
84 | In addition to object destructors, this also affects any function call |
85 | performed by XS code using the C<G_KEEPERR> flag. |
86 | |
87 | C<$@> is also no longer used as an internal temporary variable when |
88 | preparing to C<die>. Previously it was internally necessary to put |
89 | any exception object (any non-string exception) into C<$@> first, |
90 | before it could be used as an exception. (The C API still offers the |
91 | old option, so an XS module might still clobber C<$@> in the old way.) |
92 | This change together with the foregoing means that, in various places, |
93 | C<$@> may be observed to contain its previously-assigned value, rather |
94 | than having been overwritten by recent exception-related activity. |
95 | |
96 | Warnings for C<warn> can now be objects, in the same way as exceptions |
97 | for C<die>. If an object-based warning gets the default handling, |
98 | of writing to standard error, it will of course still be stringified |
99 | along the way. But a C<$SIG{__WARN__}> handler will now receive an |
100 | object-based warning as an object, where previously it was passed the |
101 | result of stringifying the object. |
102 | |
d4438f94 |
103 | =head1 New Platforms |
104 | |
105 | XXX List any platforms that this version of perl compiles on, that previous |
106 | versions did not. These will either be enabled by new files in the F<hints/> |
107 | directories, or new subdirectories and F<README> files at the top level of the |
108 | source tree. |
109 | |
110 | =head1 Modules and Pragmata |
111 | |
112 | XXX All changes to installed files in F<cpan/>, F<dist/>, F<ext/> and F<lib/> |
113 | go here. If Module::CoreList is updated, generate an initial draft of the |
114 | following sections using F<Porting/corelist-perldelta.pl>, which prints stub |
115 | entries to STDOUT. Results can be pasted in place of the '=head2' entries |
116 | below. A paragraph summary for important changes should then be added by hand. |
117 | In an ideal world, dual-life modules would have a F<Changes> file that could be |
118 | cribbed. |
119 | |
120 | =head2 New Modules and Pragmata |
121 | |
122 | =head2 Pragmata Changes |
123 | |
124 | =head2 Updated Modules |
125 | |
d6445baf |
126 | =over |
127 | |
128 | =item C<B::Deparse> |
129 | |
130 | A bug has been fixed when deparsing a nextstate op that has both a |
131 | change of package (relative to the previous nextstate), or a change of |
132 | C<%^H> or other state, and a label. Previously the label was emitted |
133 | first, leading to syntactically invalid output because a label is not |
134 | permitted immediately before a package declaration, B<BEGIN> block, |
135 | or some other things. Now the label is emitted last. |
136 | |
137 | =back |
138 | |
d4438f94 |
139 | =head2 Removed Modules and Pragmata |
140 | |
141 | =head1 Utility Changes |
142 | |
143 | XXX Changes to installed programs such as F<perlbug> and F<xsubpp> go |
144 | here. Most of these are built within the directories F<utils> and F<x2p>. |
145 | |
146 | =over 4 |
147 | |
148 | =item F<XXX> |
149 | |
150 | XXX |
151 | |
152 | =back |
153 | |
154 | =head1 New Documentation |
155 | |
156 | XXX Changes which create B<new> files in F<pod/> go here. |
157 | |
158 | =over 4 |
159 | |
160 | =item L<XXX> |
161 | |
162 | XXX |
163 | |
164 | =back |
165 | |
166 | =head1 Changes to Existing Documentation |
167 | |
168 | XXX Changes which significantly change existing files in F<pod/> go here. |
169 | Any changes to F<pod/perldiag.pod> should go in L</New or Changed Diagnostics>. |
170 | |
171 | |
172 | =head1 Performance Enhancements |
173 | |
174 | XXX Changes which enhance performance without changing behaviour go here. There |
175 | may well be none in a stable release. |
176 | |
177 | =over 4 |
178 | |
179 | =item * |
180 | |
181 | XXX |
182 | |
183 | =back |
184 | |
185 | =head1 Installation and Configuration Improvements |
186 | |
187 | XXX Changes to F<Configure>, F<installperl>, F<installman>, and analogous tools |
188 | go here. |
189 | |
190 | =head2 Configuration improvements |
191 | |
192 | XXX |
193 | |
194 | =head2 Compilation improvements |
195 | |
196 | XXX |
197 | |
198 | =head2 Platform Specific Changes |
199 | |
200 | =over 4 |
201 | |
202 | =item XXX-some-platform |
203 | |
204 | XXX |
205 | |
206 | =back |
207 | |
208 | =head1 Selected Bug Fixes |
209 | |
210 | XXX Important bug fixes in the core language are summarised here. |
211 | Bug fixes in files in F<ext/> and F<lib/> are best summarised in |
212 | L</Modules and Pragmata>. |
213 | |
214 | =over 4 |
215 | |
216 | =item * |
217 | |
218 | XXX |
219 | |
220 | =back |
221 | |
222 | =head1 New or Changed Diagnostics |
223 | |
224 | XXX New or changed warnings emitted by the core's C<C> code go here. |
225 | |
226 | =over 4 |
227 | |
228 | =item C<XXX> |
229 | |
230 | XXX |
231 | |
232 | =back |
233 | |
234 | =head1 Changed Internals |
235 | |
236 | XXX Changes which affect the interface available to C<XS> code go here. |
237 | |
238 | =over 4 |
239 | |
240 | =item * |
241 | |
242 | XXX |
243 | |
244 | =back |
245 | |
246 | =head1 New Tests |
247 | |
248 | XXX Changes which create B<new> files in F<t/> go here. Changes to |
249 | existing files in F<t/> aren't worth summarising, although the bugs that |
250 | they represent may be. |
251 | |
252 | =over 4 |
253 | |
254 | =item F<XXX> |
255 | |
256 | XXX |
257 | |
258 | =back |
259 | |
260 | =head1 Known Problems |
261 | |
262 | XXX Descriptions of platform agnostic bugs we know we can't fix go here. Any |
263 | tests that had to be C<TODO>ed for the release would be noted here, unless |
264 | they were specific to a particular platform (see below). |
265 | |
266 | This is a list of some significant unfixed bugs, which are regressions |
267 | from either 5.XXX.XXX or 5.XXX.XXX. |
268 | |
269 | =over 4 |
270 | |
271 | =item * |
272 | |
273 | XXX |
274 | |
275 | =back |
276 | |
277 | =head1 Deprecations |
278 | |
279 | XXX Add any new known deprecations here. |
280 | |
281 | The following items are now deprecated. |
282 | |
283 | =over 4 |
284 | |
285 | =item * |
286 | |
287 | XXX |
288 | |
289 | =back |
290 | |
291 | =head1 Platform Specific Notes |
292 | |
293 | XXX Any changes specific to a particular platform. VMS and Win32 are the usual |
294 | stars here. It's probably best to group changes under the same section layout |
295 | as the main perldelta |
296 | |
297 | =head1 Obituary |
298 | |
299 | XXX If any significant core contributor has died, we've added a short obituary |
300 | here. |
301 | |
302 | =head1 Acknowledgements |
303 | |
304 | XXX The list of people to thank goes here. |
305 | |
306 | |
307 | =head1 Reporting Bugs |
308 | |
309 | If you find what you think is a bug, you might check the articles |
310 | recently posted to the comp.lang.perl.misc newsgroup and the perl |
311 | bug database at http://rt.perl.org/perlbug/ . There may also be |
312 | information at http://www.perl.org/ , the Perl Home Page. |
313 | |
314 | If you believe you have an unreported bug, please run the B<perlbug> |
315 | program included with your release. Be sure to trim your bug down |
316 | to a tiny but sufficient test case. Your bug report, along with the |
317 | output of C<perl -V>, will be sent off to perlbug@perl.org to be |
318 | analysed by the Perl porting team. |
319 | |
320 | If the bug you are reporting has security implications, which make it |
321 | inappropriate to send to a publicly archived mailing list, then please send |
322 | it to perl5-security-report@perl.org. This points to a closed subscription |
323 | unarchived mailing list, which includes all the core committers, who be able |
324 | to help assess the impact of issues, figure out a resolution, and help |
325 | co-ordinate the release of patches to mitigate or fix the problem across all |
326 | platforms on which Perl is supported. Please only use this address for |
327 | security issues in the Perl core, not for modules independently |
328 | distributed on CPAN. |
329 | |
330 | =head1 SEE ALSO |
331 | |
332 | The F<Changes> file for an explanation of how to view exhaustive details |
333 | on what changed. |
334 | |
335 | The F<INSTALL> file for how to build Perl. |
336 | |
337 | The F<README> file for general stuff. |
338 | |
339 | The F<Artistic> and F<Copying> files for copyright information. |
340 | |
341 | =cut |