Fix regex seqfault 5.18 regression

This segfault is a result of an optimization that can leave the
compilation in an inconsistent state.

  /f{0}/

doesn't match anything, and hence should be removable from the regex for
all f.  However,

  qr{(?&foo){0}(?<foo>)}

caused a segfault.  What was happening prior to this commit is that
(?&foo) refers to a named capture group further along in the regex.
The "{0}" caused the "(?&foo)" to be discarded prior to setting up the
pointers between the two related subexpressions; a segfault follows.

This commit removes the optimization, and should be suitable for a
maintenance release.

One might think that no one would be writing code like this, but this
example was distilled from machine-generated code in Regexp::Grammars.

Perhaps this optimization can be done, but the location I chose for
checking it was during parsing, which turns out to be premature.  It
would be better to do it in the optimization phase of regex compilation.
Another option would be to retain it where it was, but for it to operate
only on a limited set of nodes, such as EXACTish, which would have no
unintended consequences.  But that is for looking at in the future; the
important thing is to have a simple patch suitable for fixing this
regression in a maintenance release.

For the record, the code being reverted was mistakenly added by me in
commit 3018b823898645e44b8c37c70ac5c6302b031381, and wasn't even
mentioned in that commit message.  It should have had its own commit.

Conflicts:
	regcomp.c
[perl #118649] maint-5.18: Digest-SHA crash fix in 5.85

Backported minimal changes from blead
Fix missing single quote in a sed in hints/aix.sh

(cherry picked from commit da46ab3732c369c451e8f975eeca0700552ac282)
lexsub.t: To-do tests for citing lex subs after errors

This currently causes assertion failures on debugging builds.  On
non-debugging builds (untested), it probably crashes:

my sub a { foo ref } # foo must not exist
a();
(cherry picked from commit fe54d63b71ffdc66546e8a06b4ea561f58af2fc2)
Name lexical constants

$ ./perl -Ilib -Mfeature=:all -e 'my sub a(){44} a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558.
Abort trap: 6

The experimental warning is expected.  The assertion failure is not.

When a call checker is invoked, the name of the subroutine is passed
to it.  op.c:ck_subr gets the name from the CV’s cv (CvGV) or, in the
case of lexical subs, from its name hek (CvNAME_HEK).  If neither
exists, ck_subr cannot cope.

Lexical subs never have a GV pointer.  Lexical constants were acci-
dentally having neither a GV pointer nor a hek.  They should have a
hek, like other lexical subs.
(cherry picked from commit 83a72a15a3e8908c9fea8334e083e9329d425feb)
[perl #116735] Honour lexical prototypes when no parens are used

As Peter Martini noted in ticket #116735, lexical subs produce dif-
ferent op trees for ‘foo 1’ and ‘foo(1)’.  foo(1) produces an rv2cv
op with a padcv kid.  The unparenthetical version produces just
a padcv op.

And the difference in op trees caused lexical sub calls to honour
prototypes only in the presence of parentheses, because rv2cv_op_cv
(which searches for the cv in order to check its prototype) was
expecting rv2cv+padcv.

Not realising there was a discrepancy between the two forms, and
noticing that foo() produces *two* newCVREF ops, in commit 279d09bf893
I made newCVREF return just a padcv op for lexical subs.  At the time
I couldn’t figure out why there were two rv2cv ops, and punted on
researching it.

This is how it works for package subs:

When a sub call is compiled, if there are parentheses, an implicit '&'
is fed to the parser.  The token that follows is a WORD token with a
constant op attached to it, containing the name of the subroutine.
When the parser sees '&', it calls newCVREF on the const op to create
an rv2cv op.

For sub calls without parentheses, the token passed to the parser is
already an rv2cv op.

The resulting op tree is the same either way.

For lexical subs, I had the lexer emitting an rv2cv op in both paths,
which was why we got the double rv2cv when newCVREF was returning an
rv2cv for lexical subs.

The real solution is to call newCVREF in the lexer only when there
are no parentheses, since in that case the lexer is not going to call
newCVREF itself.  That avoids a redundant newCVREF call.  Hence, we
can have newCVREF always return an rv2cv op.

The result is that ‘foo(1)’ and ‘foo 1’ produce identical op trees for
a lexical sub.

One more thing needed to change:  The lexer was not looking at the
lexical prototype CV but simply the stub to be autovivified, so it
couldn’t see the parameter prototype attached to the CV (the stub
doesn’t have one).

The lexer needs to see the parameter prototype too, in order to deter-
mine precedence.

The logic for digging through pads to find the CV has been extracted
out of rv2cv_op_cv into a separate (non-API!) routine.
(cherry picked from commit 9a5e6f3cd84e6eaf40dad034fb9d25cb3361accc)
Fix crashes after syntax errors in lexical subs

Peter Martini fixed this in commit 89e006ae4e39db for our subs.
(Thank you, BTW, if you are reading this.)

The warning is expected; the assertion failure is not:

$ ./miniperl -Ilib -Mfeature=:all -e 'state sub a { is ref } a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558.
Abort trap: 6
$ ./miniperl -Ilib -Mfeature=:all -e 'my sub a { is ref } a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (SvTYPE(_svmagic) >= SVt_PVMG), function S_mg_findext_flags, file mg.c, line 398.
Abort trap: 6
$

The prototype CV for a my sub is stored in magic attached to the pad
name.  The.  The code to fetch the prototype CV for a my sub calls
mg_find on the pad name.  If a syntax error occurs when the sub is be
ing compiled, the magic will never be attached, so the pad name (pad
names are currently SVs) will not have been upgraded to SVt_PVMG,
causing an assertion failure in mg_find, which only accepts SVs
thus upgraded.

When a pad entry is created, it is automatically filled with an empty
SV of the appropriate type.  For a subroutine, this is a nameless CV
stub.  CVs can be named in two ways, via GVs for package subs, or via
heks for lexical subs.  This stub has neither and is truly nameless.
Since a lexical sub is never installed if it contains a syntax error,
this stub is visible during subsequent compilation in the same scope.
ck_subr wasn’t prepared to handle a stub with absolutely no name
attached to it, since it is designed for handling sub calls where the
sub is known at compile time, so there must be a GV available to it,
unless the sub is lexical, and all lexical subs have heks.

This commit fixes the assumptions in both places.  Exactly what hap-
pens and what is returned is not so important, as this only hap-
pens after a syntax error, when the op tree is going to be thrown
away anyway.
(cherry picked from commit 3a74e0e282cd5c2593f9477923d3bcb1f32ece37)
[perl #118305] make dtrace sub-entry probe support lexsubs

No tests, because I don’t know how to write them.

See also <https://rt.perl.org/rt3/Ticket/Display.html?id=118305#txn-1221543>.

I have tested this manually, so I know it works and no longer crashes.

Hopefully someone else can follow this up with tests.
(cherry picked from commit 88dbe4af2506aa2aa6864e188ca115b5423d4f9b)
don't crash on deep recursion warnings in lexical subs (#118521)
(cherry picked from commit 07b2687d22462e599adb759b7c0082fb12b3f33d)
Stop undef &foo from crashing on lex subs
(cherry picked from commit bdbfc51a7bc15a2f0a187c1ef09a16838a4c9915)
perldelta for two lexsub fixes
(cherry picked from commit 81748522aff12edb368615e9512781d00a2d5d5b)
perldelta for lexsub syntax errors (3a74e0e282c)
(cherry picked from commit 3221bc400f3da87f0d721c2bf3501051fac946ea)
perldelta for #118305/88dbe4a
(cherry picked from commit 81d3ed5a0fa49c09ac57f7edc0917f345ff6b160)
perldelta for bdbfc51a7b (undef constant my sub)
(cherry picked from commit 07a522a526321341d2a83a852eda7f6fecb333c9)
perldelta: deep recursion warnings (07b2687d2/#118521)
CvGV is no longer a simple struct member access

The same slot is also used for the NAME_HEK for lexical subs, so:

- split B::CV::GV out into its own function that uses the CvGV macro

- add B::CV::NAME_HEK so the name of a lexical sub can be fetched
[perl #118525] make it work on threaded builds

(cherry picked from commit 5016d3c45a66ce5b279c253e8a8c2a38a9bd8431)
Handle /[#]/ and /[(?#]/ with code blocks

This is a regression in 5.18.0.

In something like /[#](?{})/x, the perl toker incorrectly sees the '#' as a
comment and skips the code block without parsing it.

(cherry picked from commit c30fc27b4df65a43710b25dd1d2a57d78ee2fe33)
Don’t leak the /(?[])/ parsing stack on error

Instead of creating the parsing stack and then freeing it after pars-
ing the (?[...]) construct (leaking it whenever one of the various
errors scattered throughout the parsing code occurs), mortalise it to
begin with and let the mortals stack take care of it.

(cherry picked from commit 1e4f088863436a8019c7d864691903ffdafeefda)
Stop (?[]) operators from leaking

When a (?[]) extended charclass is compiled, the various operands are
stored as inversion lists in separate SVs and then combined together
into new inversion lists.  The functions that take care of combining
inversion lists only ever free one operand, and sometimes free none.
Most of the operators in (?[]) were trusting the invlist functions to
free everything that was no longer needed, causing (?[]) compilation
to leak invlists.

(cherry picked from commit a84e671a269f736a404a62f21caacc8a431c2aca)