Improved struct pmop alignment fix - avoid the slow path on 64 bit systems.

Commit c2a50ddb1bed6576 works round an alignment bug in the slab allocator
for 32 bit systems built with 64 bit IVs. However, the C pre-processor logic
meant that the test path was enabled on true 64 bit systems. It's not needed
there, so improve the logic so that it isn't compiled for platforms where
pointers are 64 bit.
Update the GSMATCH handling in vms/gen_shrfls.pl.

This code (which only runs if you have set PERLSHR_USE_GSMATCH in
the environment) has not been updated in a long time.  It was
assuming that $] had only five digits after the decimal, whereas
it's had six for some time. And it assumed that the Perl5 version
could be represented in 4 bits, which was true up through 5.15
but isn't true anymore.

So get all the digits of the version number, and go wild and spend
5 bits on the value of $Config{PERL_VERSION}, which will get us
through 5.31.  That only leaves three bits in which to encode all
the options that could break binary compatibility, whereas in fact
we need about thirty bits.

So clearly this only works in a situation where the configuration
can be standardized and/or different configurations are packaged
separately.
Fix MidnightBSD hints file for 0.4-RELEASE

0.4 has no /usr/bin/objformat, so the hints file was
falling through to configure for aout with fatal consequences.

Confirmed that the objformat in 0.3 warns that it is deprecated.

Have switched around the logic of the checks so that it will always
configure for elf, using aout is explicitly detected.
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)