This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
[perl #128508] Fix line numbers with perl -x
authorFather Chrysostomos <sprout@cpan.org>
Sat, 2 Jul 2016 07:08:48 +0000 (00:08 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Sat, 2 Jul 2016 07:10:06 +0000 (00:10 -0700)
commitb3dd0aba3d2bf0b22280303ef6f068e976e31888
treeae33ec89b25ae5b0bde23f5f0daabdfaf0cc08fd
parentd89b078ec109c9afe0d362eabf2ee60d10ed4213
[perl #128508] Fix line numbers with perl -x

When lex_start is invoked with an SV and a handle pointer, it expects
the SV to contain the beginning of the code to be parsed.  The handle
will be read from for subsequent code.

The -x command line option happens to invoke lex_start with two non-
null pointers like this (a line and a handle), since, to find the
#!perl line, it has to read that first line out of the file handle.

There is a line of code in lex_start that adds "\n;" to the buffer
goes back to 8990e30710 (perl 5.0 alpha 6) and string eval fails
catastrophically without it.

As of v5.19.1-485-g2179133 multiple lines are supported in the current
parsing buffer (PL_linestr) when there is a file handle, and as of
v5.19.3-63-gbf1b738 the line number is correctly incremented when the
parser goes past a newline.

So, for -x, "#!perl\n" turns into "#!perl\n\n" (the final ; is skipped
as of v5.19.3-63-gbf1b738 if there is a handle).  That throws line
numbers off by one.

In the case where we have a string to parse and a file handle, the
extra "\n;" added to the end of the buffer turns out to be completely
unnecessary.  So this commit makes it conditional on rsfp.

The existing tests for -x are quite exotic.  I have made no effort to
make them less so.
t/run/switchx.aux
t/run/switchx.t
toke.c