Fix two line numbers bugs involving quote-like ops

I was going to try and fix #line directives in quote-like operators,
but I found myself fixing bug #3643 at the same time.

Before this commit, the #line directive would last until the end of
the quote-ilke operator, but not beyond:

qq{${
print __LINE__,"\n"; # 43
}};
print __LINE__,"\n"; # 5

The old method:

The lexer would scan to find the closing delimiter after seeing qq{,
incrementing the line number (CopLINE(PL_curcop)) as it went.

Then it would enter a scope for parsing the contents of the string,
with the line number localised and reset to the line of the qq{.

When it finished parsing the contents of qq{...}, it would then pop
the scope, restoring the previous value of the line number.

According to the new method:

When scanning to find the ending delimiter for qq{, the lexer still
increments CopLINE(PL_curcop), but then sets it back immediately to
the line of the first delimiter.

When parsing the contents of qq{...}, the line number is *not* local-
ised.  Instead, that’s when we increment CopLINE(PL_curcop) for real.
Hence, scan_str no longer increments the line number (except before
the starting delimiter).  It is up to callers to handle that *or* call
sublex_push.

There is some special handling for here-docs.  Here-docs’ line numbers
have to increase while the body of the here-doc is being parsed, but
then rewound back to the here-doc marker (<<END) when the code after
it on the same line is parsed.  Then when the next line break is
reached, the line number is incremented by the appropriate number for
it to hop over the here-doc body.  We already have a mechanism for
that, storing the number of lines in lex_shared->herelines.

Parsing of here-docs still happens the old way, with line num-
bers localised to the right scope.  But now we have to move
lex_shared->herelines into the inner scope’s lex_shared struct when
parsing a multiline quote other than a here-doc.

One thing this commit does not handle yet is #line inside a here-doc.

Bug #3643 was one symptom of a larger problem:

During the parsing of the contents of a quote-like operator, the
(localised) line number was incremented only in embedded code snip-
pets, not in constants parts of the string.  So

"${ warn __LINE__,
         __LINE__,
         __LINE__ }"

would correctly give ‘123’.  But this would produce the same
incorrectly:

"
foo
bar
baz
${ warn __LINE__,
         __LINE__,
         __LINE__ }"

Now the parsing of the contents of the string increments the line num-
ber in constant parts, too.

1 files changed, 9 insertions, 1 deletions

diff --git a/t/comp/parser.t b/t/comp/parser.t
index 28412da315..44106cb9d8 100644
--- a/t/comp/parser.t
+++ b/t/comp/parser.t
@@ -8,7 +8,7 @@ BEGIN {
     chdir 't';
 }
 
-print "1..162\n";
+print "1..166\n";
 
 sub failed {
     my ($got, $expected, $name) = @_;
@@ -591,6 +591,14 @@ time
 #line 42
 ;check('parser\.t', 42, 'line number after "nullary\n#line"');
 
+"${
+#line 53
+_}";
+check('parser\.t', 54, 'line number after qq"${#line}"');
+
+#line 24
+"
+${check('parser\.t', 25, 'line number inside qq/<newline>${...}/')}";
 
 __END__
 # Don't add new tests HERE. See note above