toke.c: In sublex_push use multi_close to detect here-doc

It is a lot simpler this way.  scan_heredoc already sets PL_multi_close
to '<' (the only code that does it).  That value does not appear to
be used anywhere.  Now it is.

Furthermore, this removes assumptions that the next commit will
likely violate.
Fix line numbers in <<foo,<<bar

This used to print 9:

<<foo, <<bar
a
b
c
d
e
f
g
foo
${warn __LINE__ }
bar

even though the __LINE__ marker is on line 10.  In perl 5.18, I broke
it further, making it print 2.

This commit makes it print 10.  We just need to make sure
PL_multi_start is set correctly in scan_heredoc for a second here-doc
marker on the same line.
regcomp.c:current_re_engine: Avoid %^H lookup when possible

Modification of %^H sets a flag in PL_hints, so we can check
that flag to avoid the slight overhead of has lookup if %^H
has not been used.
Respect #line directives in here-docs

#line directives in here-docs used to be ignored after the heredoc:

<<END
${
#line 27
print __LINE__,"\n" # prints 27
}
END
; print __LINE__, "\n"; # prints 7

This commit changes that by recording in PL_multi_end the end of
the here-doc (more precisely, the last line of the body, before the
terminator) during the initial parse to find the terminator.  When
the body is parsed for double-quotish stuff, at the very end (in
sublex_done) the last line number is compared with the one recorded.
Any differences are applied to the current ‘herelines’ value, which
records how many line numbers need to be skipped when the line ending
after the here-doc marked (<<END) is reached.

It conflicts with a line number workaround in op.c, which hasn’t done
anything since I accidentally disabled it in 5.18.

Added in 0244c3a40, this code set the current line number to the end
of the here-doc when creating the substitution op for s//<<foo/e.
Before that, since the line number was localised to the lexing scope,
the new line number set by the here-doc would be undone when the s///
finished, throwing off all subsequent line numbers.

Commit 83944c0156 solved the problem of the line number for code after
the here-doc marker having the wrong line number (because the here-doc
parser would increase the line number by the number of lines in the
here-doc body straightaway).  It introduced the ‘herelines’ value,
recording how many lines the here-doc body contained, but without
updating the line number yet, so that code after the <<marker would
have the right line, but the next \n would increment the line number
by herelines+1.  That accidentally stopped PL_multi_end from having
the right value, disabling the line number code in op.c.  But the
other changes rendered that code unnecessary.
Move herelines out of the lex_shared struct

Previously, the line number was localised in lexing scopes.  herelines
had to be in the lex_shared struct so that inner lexing scopes
could peek into values belonging to outer lexing scopes and set the
herelines value belonging to the same scope that a here-doc body was
extracted from.  (herelines records how much extra to increase the
line number at the next line ending, to jump over a here-doc.)

In commit ffdb8b167e, I changed things so that lexing scopes no longer
localised the line number, except for here-docs, and the line number
was incremented within the inner lexing scope, instead of during the
initial scan for the terminator.  That meant the herelines value had
to be copied into the inner lexing scope.

For nested here-docs, the inner here-doc’s body is always inside the
outer here-doc, so no peeking into outer scopes is necessary.

Hence, there is no longer any reason for herelines to be inside the
lex_shared struct.  We can put it directly inside the parser struct.
Here-docs will localise it.  Other quote-like constructs will not (and
can avoid the copy.)
Revert "Let av_push accept NULL values"

This reverts commit 7b6e8075e45ebc684565efbe3ce7b70435f20c79.

It turns out to be problematic, because it causes NULLs on the stack,
which XSUBs may trip on.

My main reason for it was actually to try to resolve some CPAN
failures, but it turns out that other fixes have removed the
need for that.
ExtUtils::Manifest has been synchronised to CPAN
op.c:newSTATEOP: remove unnecessary null check

If PL_parser is null, then the else block will crash on
PL_parser->copline.
Test line breaks in PERL5DB

$ PERL5DB='sub DB::DB{} die' perl5.18.1 -dle 'print "ok"'
Died.
$ PERL5DB='sub DB::DB{}
die' perl5.18.1 -dle 'print "ok"'
ok

So everything after the line break is ignored.

In bleadperl:

$ PERL5DB='sub DB::DB{} die' ./perl -dle 'print "ok"'
Died.
$ PERL5DB='sub DB::DB{}
die' ./perl -dle 'print "ok"'
Died at -e line 1.

Now the whole environment variable is used.  This was probably changed
by commit 2179133.

Let’s call it a bug fix and test it.

(The ‘at -e line 1’ is not right, but the next commit will fix it.)
Fix line numbers with #! -d:foo and PERL5DB=$'\n'

Commit 2179133 inadvertently stopped the PERL5DB env var from being
truncated just before the first line break.  (I’m considering that
a bug fix.)

The result is that #!perl -d:foo will throw the line numbers off by
one, as will line breaks in PERL5DB:

$ PERL5DB='sub DB::DB{}'$'\n\n\n''' ./perl -dle 'warn "ok"'
ok at -e line 4.

#!perl -d:foo has thrown off line numbers since f0e67a1d291 in 5.12.

This commit fixes both, by storing the line number of #! -d or the
number 0 for -d on the command line in the new PL_parser->preambling
member, which now overrides any number in PL_curcop.
[perl #117265] TODO tests for overloading issues
[perl #117265] correctly handle overloaded strings
[perl #117265] do most glob \0 checks in the same place

and before we do much processing
[perl #117265] move the "glob failed" warning to the point of failure

This avoids an extraneous warning when globbing fails for other reasons.
[perl #117265] fix various problems with safesyscalls

- handling "" overloading correctly
- avoid an extraneous warning from glob()
Fix assertion failure with -DT -e\"

$ ./perl -DT -e\"
Assertion failed: (s), function S_printbuf, file toke.c, line 479.
Abort trap: 6
Don’t let reblessing point SvSTASH to a half-freed stash

We should set SvSTASH before calling SvREFCNT_dec on its old value,
otherwise we could free the old stash and trigger a DESTROY that sees
the object blessed into the half-freed stash.

Currently, a second call to bless inside DESTROY can trigger ‘Attempt
to free unreferenced scalar’, because it calls SvREFCNT_dec a second
time on the stash that already has a reference count of 0.
Fix -DP output

broken by b66f3475d343.

$ ./perl -Ilib -DP
Screamer: entering, ptr=140185618803200, cnt=0
Screamer: entering: PerlIO * thinks ptr=140185618803200, cnt=%z, base=0
Screamer: going to getc, ptr=140185618803200, cnt=%z
^C

The format is %zd, not %z.
Fix buffer overflow with overlong identifiers

This was introduced by commit 32833930e32dc in 5.17.10.

$  ./perl -Ilib -e Foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Identifier too long at -e line 1.
Segmentation fault: 11

(That was an amusing use of macro parentheses for the while condition,
at least while it lasted.)
perlio.c: misuse of SvPV_nolen_const

SvPV_nolen_const takes only one argument and does not return
a length.