develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About