Bleadperl v5.17.0-326-g6a31dbf breaks PJCJ/Devel-Cover-0.89.tar.gz #12185
Comments
From @andkgit bisect 6a31dbf is the first bad commit B::Deparse: loopexes have list prec sample fail report http://www.cpantesters.org/cpan/report/9241afd6-b6d9-11e1-9c05-a8133af89482 perl -V Summary of my perl5 (revision 5 version 17 subversion 0) configuration: Characteristics of this binary (from libperl): -- |
From @pjcjOn Sat, Jun 16, 2012 at 08:39:06PM +0200, Andreas J. Koenig wrote:
Thanks again for BBC. I've been getting cpantesters failures from We've been talking about bumping version numbers before and after This commit is good. It removes some superfluous parentheses (not many -- |
From @cpansproutOn Sat Jun 16 14:57:33 2012, paul@pjcj.net wrote:
Actually, you might want to wait. I’m thinking of reverting that I noticed through experimentation that loop exits (last, next) have low Inline Patchdiff --git a/pod/perlop.pod b/pod/perlop.pod
index 3edeabd..c9a1adf 100644
--- a/pod/perlop.pod
+++ b/pod/perlop.pod
@@ -49,6 +49,7 @@ values only, not array values.
nonassoc .. ...
right ?:
right = += -= *= etc.
+ nonassoc loop exits (last, next, goto)
left , =>
nonassoc list operators (rightward)
right not
Changing the precedence of goto might break it, as it takes an arbitrary If it’s OK with you, I’ll revert the blead change for now, until we -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @pjcjOn Sat, Jun 16, 2012 at 06:49:50PM -0700, Father Chrysostomos via RT wrote:
That's fine by me. Devel::Cover will pass its tests again, and when you Thanks very much for caring about this. -- |
From @cpansproutOn Sun Jun 17 09:12:19 2012, paul@pjcj.net wrote:
I have reverted it as 23e485c. -- Father Chrysostomos |
From @cpansproutOn Sat Jun 16 18:49:49 2012, sprout wrote:
Can we try to decide how this should work? Should goto’s real -- Father Chrysostomos |
From @pjcjOn Fri, Jul 13, 2012 at 08:16:47PM -0700, Father Chrysostomos via RT wrote:
I'm probably not the right person to be opining on this, but I didn't I can't see any reason why goto should have a different precedence level So should goto's precedence be changed to that of the other loop exits, You don't say where goto sits in the precedence table at the moment, but However, I'd also imagine any breakage from such changing of precedence -- |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-07-13T23:16:47]
I'm just back from a week away, but will give this some real thought soon. -- |
From @cpansproutOn Sun Jul 22 09:38:49 2012, paul@pjcj.net wrote:
See the diff you quoted above. :-)
Perhaps I wasn’t clear. goto and last *do* have the same precedence. I placed the precedence just below assignment when trying to describe goto $a = $b; but this just makes $a the argument: goto $a, $b; However, since goto is a prefix (not infix) op, and since assignment is $a = goto $b = $c means this: $a = (goto ($b = $c))
loopexes are the only named operators with assignment precedence, and I Tangentially, I have also noticed that not() is listed with its own ... But, seeing it is a prefix op just like the other list ops, I don’t see -- Father Chrysostomos |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-07-13T23:16:47]
So, I've read over this whole ticket thread a few times, and I think that It seems to me that the current issue is twofold: 1. loop exits have a distinct precedence not in perlop's table 2. non-goto exits do not understand non-constant targets Paul seems to have understood that goto and last/next have precedences distinct Either Paul is mistaken or I am mistaken, or I am mistaken about what Paul At any rate, if I am not the mistaken one, then I think that we should document -- |
From @pjcjOn Thu, Jul 26, 2012 at 10:47:09PM -0400, Ricardo Signes wrote:
Yes, that's the impression I had got from the thread.
I'm pretty sure it's me being mistaken, which is a better state of
I think this is where I was suggesting we end up, but I had us starting -- |
From @cpansproutOn Thu Jul 26 19:48:05 2012, perl.p5p@rjbs.manxome.org wrote:
Actually, I think I have sufficiently shown that it is the same as
I have documented it in commit 2ba1f20. I have yet not updated B::Deparse to use the right predecence or fixed last 1 ? "foo" : "bar"; # same as last foo -- Father Chrysostomos |
From @cpansproutOn Fri Jul 27 10:59:47 2012, sprout wrote:
In commit 1f039d6, I have fixed loop exits to accept computed labels, In commit 1eb0b7b, I have made B::Deparse deparse them with the -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
From @pjcjOn Fri, Jul 27, 2012 at 04:29:54PM -0700, Father Chrysostomos via RT wrote:
Thanks for doing this. So now we have: $ perl -MO=Deparse -e '$a = $b || next' Those parentheses are new (from 5.16.0) and superfluous. Are they there For reference: $ perl -MO=Deparse -e '$a = $b || return' Those parentheses first appeared in 5.14.0. -- |
From @cpansproutOn Thu Aug 02 10:54:27 2012, paul@pjcj.net wrote:
Please see my explanation at -- Father Chrysostomos |
From @pjcjOn Thu, Aug 02, 2012 at 12:46:33PM -0700, Father Chrysostomos via RT wrote:
Thanks for the explanation (again). As soon as 5.17.3 comes out I'll Thanks again, -- |
From @pjcjOn Thu, Aug 02, 2012 at 09:57:45PM +0200, Paul Johnson wrote:
Just to close this out, this is fixed in Devel::Cover 0.94 with 5687c8d. (I *knew* I shouldn't have written "As soon as".) -- |
Migrated from rt.perl.org#113684 (status was 'resolved')
Searchable as RT113684$
The text was updated successfully, but these errors were encountered: