Skip Menu |

This queue is for tickets about the Devel-Declare CPAN distribution.

Report information
The Basics
Id: 76613
Status: open
Priority: 0/
Queue: Devel-Declare
People
Owner: Nobody in particular
Requestors: pthomas [...] juniper.net
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Apr 16 20:19:19 2012 pthomas [...] juniper.net - Ticket created
Subject: Devel::Declare occasionally corrupts __LINE__
Date: Mon, 16 Apr 2012 17:19:12 -0700
To: "bug-Devel-Declare [...] rt.cpan.org" <bug-Devel-Declare [...] rt.cpan.org>
From: Philip Thomas <pthomas [...] juniper.net>
The attached example creates a Devel::Declare keyword 'fun', which does nothing in the callback, and a sub called 'fun' that simply returns its argument. A closure is created inside a single-iteration for-loop, which is executed immediately, and prints its __LINE__ correctly. Finally, an identical (modulo the suffix) closure is created, and is passed through fun before being executed. This produces incorrect output, indicating that __LINE__ moved back to the line with the for loop. If the call to Devel::Declare->setup_for(...) is commented out, then both closures print the correct line number. If the for-loop is commented out (leaving the body intact), then both closures print the correct line number. Tested with Devel::Declare 0.006011 and perl v5.14.1 built for x86_64-linux-thread-multi. Phil

Message body is not shown because sender requested not to inline it.

  Mon Dec 09 09:28:41 2013 cpan [...] very.puzzling.org - Correspondence added
I think this bug might be the cause of https://rt.cpan.org/Public/Bug/Display.html?id=87544 in Method::Signatures as well. Somewhat frustrated with the latter bug, I took a look inside Devel::Declare to see if I could narrow the problem down. I don't really know enough about Perl's internals to have any idea what I'm doing, but I did discover that removing the following line seemed to make the problem go away: diff --git a/Declare.xs b/Declare.xs index 47f9482..d64c43e 100644 --- a/Declare.xs +++ b/Declare.xs @@ -322,7 +322,7 @@ STATIC OP *dd_ck_rv2cv(pTHX_ OP *o, void *user_data) { if (PL_expect != XOPERATOR) { if (!dd_handle_const(aTHX_ GvNAME(kGVOP_gv))) return o; - CopLINE(PL_curcop) = PL_copline; + /* CopLINE(PL_curcop) = PL_copline; */ /* The parser behaviour that we're simulating depends on what comes after the declarator. */ if (*skipspace(PL_bufptr + strlen(GvNAME(kGVOP_gv))) != '(') { I figured that changing the op's line number seemed like the wrong thing to do... and with this change all the tests still pass and the line numbers are no longer screwed up. If it's of any significance, I'm running Perl 5.16.3 built for x86_64-linux-thread-multi.
  Mon Dec 09 09:28:43 2013 The RT System itself - Status changed from 'new' to 'open'
  Thu Jan 30 09:18:02 2014 cpan [...] very.puzzling.org - Correspondence added
On Mon Dec 09 09:28:41 2013, MCHAPMAN wrote: Show quoted text
> I figured that changing the op's line number seemed like the wrong > thing to do... and with this change all the tests still pass and the > line numbers are no longer screwed up.
Any chance this could be looked into soon? This is a pretty frustrating bug. I'd be happy even if the response was "no, that's a silly patch, and here's why..." :-)
  Sun Jan 04 18:46:36 2015 cpan [...] very.puzzling.org - Correspondence added
Ping.... again! :-) This bug still exists with Devel::Declare 0.006017 running under Perl 5.20.1. My patch in an earlier comment still seems to fix the problem.