[perl #118931] Fix line number bug
Commit 2179133 (in 5.19.2) introduced this line number bug when it
modified the parser to look past newlines when searching for => after
a keyword:
$ perl5.19.3
1 unless
1;
warn;
^D
Warning: something's wrong at - line 2.
The warning should say line 3, not 2.
Before 2179133, the parser’s line-reading algorithm work strictly in
two modes: From a file, one line would be read into PL_linestr at a
time. In a string eval, PL_linestr would contain all the code.
To be able to look past a newline to find => after a keyword, the
parser’s former mode had to be adjusted:
• It has to be possible to append more lines of input to the buffer
without incrementing the line number.
• When reading from a filehandle, the lexer should not assume when it
sees "\n" that it has reached the end of the buffer.
Commit 2179133 did those two things.
It did not, however, make the lexer increment the line number when
encountering a newline in the middle of it (when reading from a han-
dle; string eval follows a different code path).
Fixing it to do that requires that lex_start be adjusted, too. When
lexing begins, PL_linestr is set to "\n;" when there is no string to
eval. This worked for file handles because the lexer, on seeing the
\n, would ignore the semicolon.
Now that it no longer ignores the semicolon, it will end up incre-
mented the line number erroneously at the outset, so set the buffer
to just "\n" instead.
In one place (skipspace2), the mad-specific code was setting PL_bufptr
to point at its previous location after calling skipspace. skipspace
sets it to point after the newline to prevent incline() from being
called a second time for the same newline. But this is exactly what
happens if skipspace2 resets PL_bufptr. The callers of skipspace2
apparently don’t depend on this, so we can remove it.