Front page | perl.perl5.porters |
Postings from July 2013
Re: upcoming release of 5.18.1
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
July 27, 2013 20:46
Subject:
Re: upcoming release of 5.18.1
Message ID:
20130727204636.GD11816@cancer.codesimply.com
* David Golden <xdg@xdg.me> [2013-07-24T11:50:22]
> [stuff]
First off, thanks for your summary! I've had a look though it to see which
things are already applied or obviously suitable and easy to pick.
I have re-ordered the original list to group it by status.
> * The debugger's "man" command been fixed. It was broken in the v5.18.0
> release. The "man" command is aliased to the names "doc" and "perldoc"
> - all now work again.
This is b019bbd28397aba60a9673fa89dded4500c6c783. I'd like to get this
applied. It did not "just apply," so I left it for later for now.
> * Certain uses of the "sort" operator are optimised to modify an array
> in place, such as "@a = sort @a". During the sorting, the array is
> made read-only. If a sort block should happen to die, then the array
> remained read-only even outside the "sort". This has been fixed.
I am unsure whether this was a regression from 5.16. The original commit is
20d5dc239. I am doing nothing, here. If others want to speak to its
appropriateness for maint, they should do so.
> * Method calls on typeglobs (e.g., "*ARGV->getline") used to stringify
> the typeglob and then look it up again. Combined with changes in Perl
> 5.18.0, this allowed "*foo->bar" to call methods on the "foo" package
> (like "foo->bar"). In some cases it could cause the method to be
> called on the wrong handle. Now a typeglob argument is treated as a
> handle (just like "(\*foo)->bar"), or, if its IO slot is empty, an
> error is raised.
This is a77c16f7c797af630db968764807f48bed555b91. I am also declining to do
anything directly, here.
> * Through certain conundrums, it is possible to cause the current
> package to be freed. Certain operators ("bless", "reset", "open",
> "eval") could not cope and would crash. They have been made more
> resilient. [RT #117941]
RT suggests the commits are: 94e7eb6, dcdfe74, cb1ad50, e39b51c. They apply
cleanly to blead, at least. Do we want to cherry pick these? The bug seems
worth fixing.
> * Lexical constants ("my sub a() { 42 }") no longer crash when inlined.
¿ 83a72a15a3e8908c9fea8334e083e9329d425feb ?
¿ 9a5e6f3cd84e6eaf40dad034fb9d25cb3361accc ?
> * Syntax errors in lexical subroutines in combination with calls to the
> same subroutines no longer cause crashes at compile time.
3a74e0e282cd5c2593f9477923d3bcb1f32ece37
> * Parameter prototypes attached to lexical subroutines are now respected
> when compiling sub calls without parentheses. Previously, the
> prototypes were honoured only for calls with parentheses. [RT #116735]
9a5e6f3cd84e6eaf40dad034fb9d25cb3361accc
> * The dtrace sub-entry probe now works with lexical subs, instead of
> crashing [perl #118305].
2 88dbe4af2506aa2aa6864e188ca115b5423d4f9b
> * Undefining an inlinable lexical subroutine ("my sub foo() { 42 } undef
> &foo") would result in a crash if warnings were turned on.
1 bdbfc51a7bc15a2f0a187c1ef09a16838a4c9915
HEY SPROUT: It would be great if you were interested in porting these back to
a branch atop maint-5.18. ;)
> * "./Configure -de -Dusevendorprefix" didn't default [RT #64126]
Appears to be 8f1aac9885804c62afc10b9ffb5697e76d761701. I have no opinion
about this one.
> * Since Perl v5.12, inlining of constants that override built-in
> keywords of the same name had countermanded "use subs", causing
> subsequent mentions of the constant to use the built-in keyword
> instead. This has been fixed.
This is 70e5f2b56cbcbdf658cf4172827db4611d322148. It's fixing a regression in
v5.12. I'm happy to let that wait for 5.20, unless there is call for this.
If there is, someone else must do the backporting, as it does not apply.
> Memory leaks:
> * Various memory leaks involving the parsing of the "(?[...])" regular
> expression construct have been fixed.
This is, I think, a collection of commits.
> * "delete local $ENV{nonexistent_env_var}" no longer leaks memory.
9332b95f7, does not apply cleanly.
> * The OP allocation code now returns correctly aligned memory in all
> cases for "struct pmop". Previously it could return memory only
> aligned to a 4-byte boundary, which is not correct for an ithreads
> build with 64 bit IVs on some 32 bit platforms. Notably, this caused
> the build to fail completely on sparc GNU/Linux. [RT #118055]
I *think* this is already applied, as per
https://rt.perl.org/rt3/Ticket/Display.html?id=118055#txn-1227779
> * Fixed a small number of regexp constructions that could either fail to
> match or crash perl when the string being matched against was
> allocated above the 2GB line on 32-bit systems. [RT #118175]
Already in maint as 4149c7198d9b78d861df289cce40dd865cab57e7.
> * @_ is now correctly visible in the debugger, fixing a regression
> introduced in v5.18.0's debugger. [RT #118169]
Already in maint as 70a2dad880f94d9f3789e347e581bce94d4c41da.
> * Perl v5.16 inadvertently introduced a bug whereby calls to XSUBs that
> were not visible at compile time were treated as lvalues and could be
> assigned to, even when the subroutine was not an lvalue sub. This has
> been fixed. [RT #117947]
Already in maint as dffdb99.
> * In Perl v5.18.0 dualvars that had an empty string for the string part
> but a non-zero number for the number part starting being treated as
> true. In previous versions they were treated as false, the string
> representation taking precedeence. The old behaviour has been
> restored. [RT #118159]
Already in maint as 55d1519425e224c2d9facd6ef8da8ee1e9e7b09e.
> * Perl v5.18 inadvertently introduced a bug whereby interpolating mixed
> up- and down-graded UTF-8 strings in a regex could result in malformed
> UTF-8 in the pattern: specifically if a downgraded character in the
> range "\x80..\xff" followed a UTF-8 string, e.g.
>
> utf8::upgrade( my $u = "\x{e5}");
> utf8::downgrade(my $d = "\x{e5}");
> /$u$d/
>
> [RT #118297]
Already in maint as ae335535b7b632.
--
rjbs
Thread Previous
|
Thread Next