Mailing List Archive: Perl: porters

[perl #114040] Multiline constructs in regexp blocks

Index | Next | Previous | View Threaded

perlbug-comment at perl

Aug 6, 2012, 8:38 PM

Post #1 of 9 (132 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks

I fixed formats in commit 583c9d5, uncovering umpteen other bugs at the
same time....

--

Father Chrysostomos

perlbug-comment at perl

Aug 17, 2012, 2:34 PM

Post #2 of 9 (112 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Mon Jul 09 06:29:12 2012, davem wrote:
> On Sun, Jul 08, 2012 at 02:18:36PM -0700, Father Chrysostomos wrote:
> > These all fail to parse with bleadperl, but work in 5.16:
> [snip]
> > /(?{ <<END
> > END
> > })/;
>
> Note that the bleadperl change just made literal (?{}) be handled
> similarly to how array and hash indexes have always been parsed in
> interpolating strings. So this fails, and always has:
>
> qq[.$a{ do {
> <<END
> foo
> END
> }}];

This is actually a hard one. This works, and always has:

s//<<END
/e;
blah blah blah
END

I seem to remember writing code that relies on that, too.

These work, too:

s/${ <<END
}//;
blah blah blah
END

m/${ <<END
}/;
blah blah blah
END

"${ <<END
}";
noet oteuhhnto e
END

For consistency with historical behaviour, we would have to make this work:

/(?{ <<END
})/
oentuh oenuth
END

--

Father Chrysostomos

perlbug-comment at perl

Aug 17, 2012, 4:48 PM

Post #3 of 9 (109 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Sun Jul 08 14:18:36 2012, sprout wrote:
> # pod
> /(?{
>
> =pod
>
> onuthoen oeun hoeun oue
>
> =cut
>
> })/

Pod is fixed in commit 4a7239ff0b.

--

Father Chrysostomos

perlbug-comment at perl

Aug 18, 2012, 2:24 PM

Post #4 of 9 (107 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Fri Aug 17 14:34:10 2012, sprout wrote:
> On Mon Jul 09 06:29:12 2012, davem wrote:
> > On Sun, Jul 08, 2012 at 02:18:36PM -0700, Father Chrysostomos wrote:
> > > These all fail to parse with bleadperl, but work in 5.16:
> > [snip]
> > > /(?{ <<END
> > > END
> > > })/;
> >
> > Note that the bleadperl change just made literal (?{}) be handled
> > similarly to how array and hash indexes have always been parsed in
> > interpolating strings. So this fails, and always has:
> >
> > qq[.$a{ do {
> > <<END
> > foo
> > END
> > }}];
>
> This is actually a hard one. This works, and always has:
>
> s//<<END
> /e;
> blah blah blah
> END
>
> I seem to remember writing code that relies on that, too.
>
> These work, too:
>
> s/${ <<END
> }//;
> blah blah blah
> END
>
> m/${ <<END
> }/;
> blah blah blah
> END
>
> "${ <<END
> }";
> noet oteuhhnto e
> END
>
> For consistency with historical behaviour, we would have to make this
work:
>
> /(?{ <<END
> })/
> oentuh oenuth
> END
>

But those don’t work in string eval. In fact, they crash in every
version from 5.6.2 to 5.17.3.

So is the solution to break the examples above and make deer hocks work
the way they are documented?

s//<<end
blah blah blah
end
/e;

--

Father Chrysostomos

perlbug-comment at perl

Aug 18, 2012, 10:20 PM

Post #5 of 9 (109 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Sat Aug 18 14:47:48 2012, doy [at] tozt wrote:
> On Sat, Aug 18, 2012 at 02:24:14PM -0700, Father Chrysostomos via RT
wrote:
> > But those don’t work in string eval. In fact, they crash in every
> > version from 5.6.2 to 5.17.3.

Actually, it’s just substitution that crashes in string eval. It
probably has since 0244c3a403af.

> >
> > So is the solution to break the examples above and make deer hocks work
> > the way they are documented?
> >
> > s//<<end
> > blah blah blah
> > end
> > /e;
>
> s//<<end
> blah blah blah
> end
> /e;
>
> makes a lot more sense to me than
>
> s//<<end
> /e;
> blah blah blah
> end

Indeed, if you use m//, the former works in string eval, but not the
latter (the other way round outside string eval).

>
> I think this would be a reasonable change to make (especially if this
> behavior has been pretty flaky so far).

--

Father Chrysostomos

perlbug-comment at perl

Aug 18, 2012, 11:20 PM

Post #6 of 9 (108 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Sat Aug 18 22:20:14 2012, sprout wrote:
> On Sat Aug 18 14:47:48 2012, doy [at] tozt wrote:
> > On Sat, Aug 18, 2012 at 02:24:14PM -0700, Father Chrysostomos via RT
> wrote:
> > > But those don’t work in string eval. In fact, they crash in every
> > > version from 5.6.2 to 5.17.3.
>
> Actually, it’s just substitution that crashes in string eval. It
> probably has since 0244c3a403af.
>
> > >
> > > So is the solution to break the examples above and make deer hocks
work
> > > the way they are documented?
> > >
> > > s//<<end
> > > blah blah blah
> > > end
> > > /e;
> >
> > s//<<end
> > blah blah blah
> > end
> > /e;
> >
> > makes a lot more sense to me than
> >
> > s//<<end
> > /e;
> > blah blah blah
> > end
>
> Indeed, if you use m//, the former works in string eval, but not the
> latter (the other way round outside string eval).
>
> >
> > I think this would be a reasonable change to make (especially if this
> > behavior has been pretty flaky so far).

More madness:

This works:

print <<EOF;
${\<<EOG}
going to acquire practice
EOG
EOF

But this fails:

print <<`EOF`;
${\<<EOG}
echo going to acquire practice
EOG
EOF
__END__
Can't find string terminator "EOG" anywhere before EOF at - line 1.

But you can put the inner deer hock’s body after the outer one:

print <<`EOF`;
${\<<EOG}
EOF
echo going to a choir practice
EOG

That discrepancy was caused by commit a2c066523a, but the latter was how
<<foo and <<"foo" worked before fd2d09532. This has an interesting
history. :-)

--

Father Chrysostomos

perlbug-comment at perl

Aug 19, 2012, 12:16 AM

Post #7 of 9 (108 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

perlbug-comment at perl

Aug 22, 2012, 4:10 PM

Post #8 of 9 (100 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Sun Jul 08 14:18:36 2012, sprout wrote:
> These all fail to parse with bleadperl, but work in 5.16:

> # deer hocks
> /(?{ <<END
> END
> })/;

Now fixed by 5097bf9b8 and db4442662555874019, except for this, which
has always crashed and still does:

/(?{s||${<<END}|
END
})/

This case, however, crashes now (as of the re-eval jumbo fix):

/(?{m|${<<END}|
END
})/

whereas it used to do this:

Can't find string terminator "
END" anywhere before EOF at (re_eval 1) line 1.
Compilation failed in regexp at - line 3.

or, before, 5.14:

panic: top_env

So we still have a regression here.

--

Father Chrysostomos

perlbug-comment at perl

Aug 28, 2012, 11:07 PM

Post #9 of 9 (92 views)
Permalink

[perl #114040] Multiline constructs in regexp blocks [In reply to]

On Wed Aug 22 16:10:19 2012, sprout wrote:
> On Sun Jul 08 14:18:36 2012, sprout wrote:
> > These all fail to parse with bleadperl, but work in 5.16:
>
> > # deer hocks
> > /(?{ <<END
> > END
> > })/;
>
> Now fixed by 5097bf9b8 and db4442662555874019, except for this, which
> has always crashed and still does:
>
> /(?{s||${<<END}|
> END
> })/
>
> This case, however, crashes now (as of the re-eval jumbo fix):
>
> /(?{m|${<<END}|
> END
> })/
>
> whereas it used to do this:
>
> Can't find string terminator "
> END" anywhere before EOF at (re_eval 1) line 1.
> Compilation failed in regexp at - line 3.
>
> or, before, 5.14:
>
> panic: top_env
>
> So we still have a regression here.

Actually, those crash because of the last-used-pattern rule, which
results in infinite recursion in these cases.

--

Father Chrysostomos

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads