develooper Front page | perl.perl5.porters | Postings from December 2013

[perl #119593] Bleadperl v5.19.3-296-gffdb8b1 breaks BAREFOOT/Test-File-1.34.tar.gz

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
December 22, 2013 02:07
Subject:
[perl #119593] Bleadperl v5.19.3-296-gffdb8b1 breaks BAREFOOT/Test-File-1.34.tar.gz
Message ID:
rt-4.0.18-17120-1387678028-602.119593-15-0@perl.org
On Sat Sep 07 18:47:34 2013, sprout wrote:
> On Sat Sep 07 01:20:26 2013, sprout wrote:
> > On Tue Sep 03 19:58:33 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de
> wrote:
> > > git bisect
> > > ----------
> > > commit ffdb8b167ec4e9c0f37371dfd7b0abb01e413f90
> > > Author: Father Chrysostomos <sprout@cpan.org>
> > > Date:   Sun Sep 1 00:30:59 2013 -0700
> > > 
> > >     Fix two line numbers bugs involving quote-like ops
> > 
> > The Test::File failure can be reduced to:
> > 
> > foo(
> >    "@{[]}"
> >  . warn() # now gives line 1, not 2
> >  . "")
> > 
> > The line number returned by caller() (and used by warn) is a single
> > number applying to the whole statement.  A multiline statement only gets
> > one line number assigned to it in the op tree.
> > 
> > "@{[]}" used to reset the line number for the surrounding statement to
> > the line number of the "@{[]}" itself.  Now it has stopped doing that,
> > although @{[]} without quotes still does it.
> > 
> > The reason this happens is that PL_copline is now localised and
> > invalidated for the compilation of the contents of the quotes, so that
> > statements inside the quotes don’t pick up the line number from outside.
> > 
> > Test::File’s test suite is sensitive to that, as it uses
> > Test::Builder::Tester::line_num (which uses caller), rather than
> > __LINE__.  __LINE__ is not subject to the one-number-per-statement
> > limitation.
> > 
> > As long as we are limited to one line number per statement, which line
> > should we be aiming for?  To me, the first line makes sense, so it looks
> > as though I have partially fixed a bug here.
> > 
> > If necessary, though, I could allow changes to PL_copline inside the
> > quotes to leak out, but still protect code inside from the previous
> > PL_copline value from outside.
> > 
> > (For those who have no idea what I am talking about, PL_copline is set
> > at the beginning of certain possibly multiline constructs, and then
> > newSTATEOP [which creates the statement] uses that value for the line
> > number if it is set.  The idea is to report beginning, rather than
> > ending, line numbers.  Currently PL_copline is not used enough, IMO.)
> 
> Maybe the best solution here is to allow entersub ops to store a line
> number.
> 
> Maybe all ops should store a line number....  (I’m not the first to
> suggest that.  It was brought up in another ticket a long time ago.)

Could someone else familiar with ops review my suggestions?

Should I
• make all ops store line numbers, fixing numerous bugs and
  increasing memory usage,
• introduce a new SUBOP op type that includes a line number or
• make PL_copline localisation only protect the inner value, not
  the outer?

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=119593

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