Front page | perl.perl5.porters |
Postings from July 2013
Re: upcoming release of 5.18.1
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
July 28, 2013 06:48
Subject:
Re: upcoming release of 5.18.1
Message ID:
20130728064825.14407.qmail@lists-nntp.develooper.com
rjbs:
> * David Golden <xdg@xdg.me> [2013-07-24T11:50:22]
> > * Certain uses of the "sort" operator are optimised to modify an array
> > in place, such as "@a =3D 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.
From 5.8.
> The original commit is
> 20d5dc239. I am doing nothing, here. If others want to speak to its
> appropriateness for maint, they should do so.
Breaks binary compatibility.
> > * Method calls on typeglobs
...
> This is a77c16f7c797af630db968764807f48bed555b91. I am also declining to do
> anything directly, here.
I am not comfortable backporting that.
The only "regression" is that some questionable method calls started
being permitted in 5.18. The rest of the commit changes longstanding
behaviour to cause less astonishment.
> > * 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.
+4
> > * Lexical constants ("my sub a() { 42 }") no longer crash when inlined.
>
> ¿ 83a72a15a3e8908c9fea8334e083e9329d425feb ?
That is it. +1
> ¿ 9a5e6f3cd84e6eaf40dad034fb9d25cb3361accc ?
No, but see below, where you cited it under the correct item.
> > * Syntax errors in lexical subroutines in combination with calls to the
> > same subroutines no longer cause crashes at compile time.
>
> 3a74e0e282cd5c2593f9477923d3bcb1f32ece37
+1
> > * 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
+1, plus 3a74e0e282cd depends on this.
Also: 07b2687d2: deep recursion warnings making lexsubs crash
> > * The dtrace sub-entry probe now works with lexical subs, instead of
> > crashing [perl #118305].
>
> 2 88dbe4af2506aa2aa6864e188ca115b5423d4f9b
+1
> > * Undefining an inlinable lexical subroutine ("my sub foo() { 42 } undef
> > &foo") would result in a crash if warnings were turned on.
>
> 1 bdbfc51a7bc15a2f0a187c1ef09a16838a4c9915
+1
> HEY SPROUT: It would be great if you were interested in porting these back to
> a branch atop maint-5.18. ;)
sprout/lexsub-5.18, which does not exist yet, but might by the time you
read this.
> > * "./Configure -de -Dusevendorprefix" didn't default [RT #64126]
>
> Appears to be 8f1aac9885804c62afc10b9ffb5697e76d761701. I have no opinion
> about this one.
I know very little about the build system. Let's keep it that way.
> > * 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.
+1 if anyone wants to do it. Not high priority.
(If I +1 something that nobody has +1ed, do I get an uninitialized
warning?)
> > Memory leaks:
> > * Various memory leaks involving the parsing of the "(?[...])" regular
> > expression construct have been fixed.
>
> This is, I think, a collection of commits.
1e4f088 a84e671 c80d037 4bc5d08 b573e70
+5
> > * "delete local $ENV{nonexistent_env_var}" no longer leaks memory.
>
> 9332b95f7, does not apply cleanly.
+1 if anyone wants to tackle it.
Thread Previous
|
Thread Next