move Perl_ck_warner() before unwind [perl #113794]

Indeed. The Perl_ck_warner() call in die_unwind() used to happen
before unwinding, so would be affected by the lexical warning state
at the die() site. Now it happens after unwinding, so takes the
lexical warning state at the catching site. I don't have a clear
idea of which behaviour is more correct. t/op/die_keeperr.t, which
was introduced as part of my exception handling changes, is actually
testing for the catching-site criterion, but that's not asserting
that the criterion should be that.  The documentation speaks of "no
warnings 'misc'", but doesn't say which lexical scope matters.

Assuming we want to revert this change, the easy fix is to move the
conditional Perl_ck_warner() back to before unwinding. A more
difficult way would be to determine the disposition of the warning
before unwinding and then warn in the required manner after
unwinding.  I see no compelling reason to warn after unwinding
rather than before, so just moving the warning code should be fine.

Note from the committer: This patch was supplied by Zefram in
https://rt.perl.org/rt3/Ticket/Display.html?id=113794#txn-1204749
with a note that some extra work was required for
ext/XS-APItest/t/call.t before the job was done.  Ricardo Signes
applied this patch and followed Zefram's lead in patching
ext/XS-APItest/t/call.t without being 100% certain that this was
what was meant.  This commit was then submitted for review.
PUSH_MULTICALL_WITHDEPTH becomes ..._FLAGS

Two non-API macros were added with 5.17.1 to support the more
complex calling conventions required by /({})/ code blocks:

    PUSH_MULTICALL_WITHDEPTH(the_cv, depth)
    CHANGE_MULTICALL_WITHDEPTH(the_cv, depth)

which allowed us to do the same as the API versions, but to optionally
not increment the caller depth, and to change the current CV.

Replace these with two new macros:

    PUSH_MULTICALL_FLAGS(the_cv, flags)
    CHANGE_MULTICALL_FLAGS(the_cv, flags)

which instead allow us to set extra flags in cx->cx_type.
The depth increment skip is handled by the new CXp_SUB_RE_FAKE flag,
and all (?{}) calls set the new CXp_SUB_RE flag.

These two new flags will shortly allow us to change how caller() and
__SUB__ handle code blocks.
fix caller with re_evals.

(See RT #113928)

In code like

    sub foo {  /A(?{ bar; caller(); }B/; }

the regex /A(?{B})C/ is, from a scope point of view, supposed to
be compiled and executed as:

    /A/ && do { B } && /C/;

i.e. the code block in B is part of the same sub as the code surrounding
the regex. Thus the result of caller() above should see the caller as
whoever called foo.

Due to an implementation detail, we actually push a hidden extra
sub CX before calling the pattern. This detail was leaking when caller()
was used. Fux it so that it ignores this extra context frame.

Conversely, for a qr//, that *is* supposed to be seen as an extra level
of anonymous sub, so add tests to ensure that is so.
i.e.

    $r = qr/...(?{code}).../
    /...$r.../

is supposed to behave like

    $r = sub { code };
    $r->();
make qr/(?{ __SUB__ })/ safe

(See RT #113928)

Formerly, __SUB__ within a code block within a qr// returned
a pointer to the "hidden" anon CV that implements the qr// closure. Since
this was never designed to be called directly, it would SEGV if you tried.

The easiest way to make this safe is to skip any CXt_SUB frames that
are marked as CXp_SUB_RE: i.e. skip any subs that are there just to
execute code blocks. For a qr//, this means that we return the sub which
the pattern match is embedded in.

Also, document the behaviour of __SUB__ within code blocks as being
subject to change. It could be argued for example that in these cases it
should return undef. But with the 5.18.0 release a month or two away, just
make it safe for now, and revisit the semantics later if necessary.
t/op/smartkve.t: single-quote some eval stuff

Three tests were wrong because they incorrectly double- rather than
single-quoted an eval string like

    eval "keys $hash ...."

Since the tests were supposed to generate syntax errors anyway it didn't
show up. However, the $hash ref was being expanded to HASH(0x......)
and on some platform / compiler permutations it would generate some
mysterious

    Hexadecimal number > 0xffffffff non-portable

warnings.
[perl #117607] TODO test for \&CORE::lc in error context

The original sample was:

BEGIN {
$^H |= 0x00000400; # strict vars
}
# Undeclared variable here
sub foo { return $anyvar; }
# Any CORE:: here
sub bar { \&CORE::lc }

simplified to:

BEGIN {
$^H |= 0x00000400; # strict vars
}
$anyvar;
&CORE::lc;

but it occurs for any compile-time error that doesn't abort compilation,
such as:

$foo/; \&CORE::lc
[perl #117607] don't use a CV after it's been freed
[perl #117607] don't crash on: use strict; $foo; &CORE::lc
[perl #117743] don't warn on $@ = undef; die;

and fix the test that's meant to detect this bug.
updating README.macosx to reflect current systems.
update known_pod_issues.dat to account for the README.macosx change

The insanely long directory name gave us an extra verbatim line over
79 characters.
Remove a comment made obsolete by commit 213f370f28504f3a.

Commit 213f370f28504f3a enabled running tests in t/op/*.t in parallel. It
should also have removed the comment saying that this would be nice to have.
Update HP-UX readme

The porting center cannot be said to ship recent perl when 5.18.0 is about
to be released and they just have 5.10.1 available. Trying "very hard" now
sounds like a huge overstatement. Sadly.

Telling what modules were included in the first public perl port from HP is
like digging up corpses.

HP-UX 11.31 has now EOL set to 2022. I've updated all other EOL info too.
I cannot find shorter URL's
Carp: distinguish deleted stash from top of stack

The change to work with deleted stashes broke the behavior of Carp
at the top of the stack.

This change distinguishes between the two cases: at the top of the
stack, caller(1) returns ().  If the stash has been deleted, it
returns a populated list with an undefined package name.  The test
used here is to check for a defined line number, which should be
sufficient.
Carp: add a test for top-of-stack longmess
reg_mesg.t: Turn off regexp warns along with deprecated

Some warnings are both regexp and deprecated.  To test that they are
under control of 'deprecated', it is necessary to turn off both
categories.  We currently don't test that they are also under 'regexp'
control
PATCH: [perl #117327]: Sequence (?#...) not recognized in regex

This reverts commit 504858073fe16afb61d66a8b6748851780e51432, which
was made under the erroneous belief that certain code was unreachable.
This code appears to be reachable, however, only if the input has
a 2-character lexical token split by space or a comment.  The token
should be indivisible, and was accepted only through an accident of
implementation.  A later commit will deprecate splitting it, with the
view of eventually making splitting it a fatal error.  In the meantime,
though, this reverts to the original behavior, and adds a (temporary)
test to verify that.
lib/utf8_heavy.pl: Fix separated '(?' token

The next commit will warn when these aren't adjacent
Deprecate spaces/comments in some regex tokens

This commit deprecates having space/comments between the first two
characters of regular expression forms '(*VERB:ARG)' and '(?...)'.
That is, the '(' should be immediately be followed by the '*' or '?'.
Previously, things like:

   qr/((?# This is a comment in the middle of a token)?:foo)/

were silently accepted.

The problem is that during regex parsing, the '(' is seen, and the input
pointer advanced, skipping comments and, under /x, white space, without
regard to whether the left parenthesis is part of a bigger token or not.
S_reg() handles the parsing of what comes next in the input, and it
just assumes that the first character it sees is the one that
immediately followed the input parenthesis.

Since the parenthesis may or may not be a part of a bigger token, and
the current structure of handling things, I don't see an elegant way to
fix this.  What I did is flag the single call to S_reg() where this
could be an issue, and have S_reg check for for adjacency if the
parenthesis is part of a bigger token, and if so, warn if not-adjacent.