D:P: HACKERS: Correct misstatement

Replacement regions work the opposite way round what it said.

D:P: HACKERS: Update for modern test infrastructure

D:P: PATCH: gh #156 sync_locale doesn't work in 5.20 maint

It turns out that there was special code added in the 5.20 maint series
that needed to be accounted for.

D:P: devel/regenerate: Update script name

which has changed from .sh to .pl

D:P: parts/apidoc.fnc: Update to latest blead

D:P: Convert ok() to is()

There are some ok() that need to remain so, but this converts all the
ones that are really is() to be that.

After this commit, the remaining ok() can have a test description added
to them.

D:P: Change to use modern skip functionality

The new skip() has a count of tests.  Previously you had to loop
yourself.

D:P: Convert to use modern Test functions

This commit copies much of test.pl from blead to replace the Test ones.

These versions are much friendlier to use.  Several .t files required
minor changes to work with these.  pv_tools.t was the only file using
the old obsolete skip() functionality fully.  The new version does not
do a 'last SKIP', for compatibility.

like and unlike were not ported because of the absence of qr// in perls
this is supposed to work on.

And the portions of test.pl that were copied also required a few minor
changes to work back to 5.3.7.

Not all the ported functionality is currently in used.  It may be that
changes will have to be made to it to get it to work; or will have to be
deleted.

D:P: fix mess.t failures when $0 contains backslashes

This seems to happen only when Devel::PPPort was built with
Visual C++ and nmake as a standalone distribution.

perl/perl5@1ddd2f5fcd8802a45ffd773aec3af107f37613f6 had fixed that
before, but the change was made only in the autogenerated test file
and it was discarded when the tests were regenerated.

Devel::PPPort: Bump version to 3.56

Fix MYMALLOC (PERL_MALLOC) build on Windows

Commit 34716e2a6e changed the WIN32 version of Perl_my_setenv() from using
Newx() to using safesysmalloc() (in S_env_alloc()), but neglected to make
the corresponding change from Safefree() to safesysfree().

PATCH: gh #17275 Silence new warning

This was caused by a static inline function in a header that was
 #included in a file that didn't use it.  Normally, these functions are
 #ifdef'd so as to be visible only to files in which they are used.
 Some compilers warn that the function is defined but not used
 otherwise.  The solution is to remove this function's visibility from
 the file that didn't use it.

regcomp.c: Fix order of fcn declaration

The static comes before the return type

Properly handle filled /il regnodes and multi-char folds

Previously we were ignoring this possibility.  Suppose a pattern being
compiled under /il contains 'SS', and that it so happens that a regnode
becomes filled with the first 'S', so that the next regnode would begin
with the second one.  If at runtime, the locale is UTF-8, the pattern
should match match a LATIN SHARP S.  Until this commit, it wouldn't.
The commit just extends the current mechanism used in this situation (of
a filled regnode) for non-/l patterns.

If the locale isn't a UTF-8 one, the 'SS' sequence shouldn't match the
SHARP S, and it won't, but we have to construct the node so that it can
handle the UTF-8 case.

Try to find the appropriate SHAs

We want all the patches between the branch-off point from
blead and the current branch. The current branch position lives in
$ENV{GITHUB_SHA}, and the (latest) branch-off point from blead is
found by running

    git merge-base $ENV{GITHUB_BASE_REF} $ENV{GITHUB_HEAD_REF}

We don't want to use the last commit, as it's a merge commit.

That commit will also have the Github mail address, not the real
git mail address of the author . Instead we use the (second)
parent commit to that merge commit.

Update Module::CoreList for 5.31.7

Bump the perl version in various places for 5.31.7

new perldelta for v5.31.7

Update epigraphs.pod for v5.31.6 one

Merge branch 'release-5.31.6' into blead

regcomp.c: Add invlist_lowest() and use it

This makes it less complicated to find the lowest code point in an
inversion list.  This makes the place where it's used clearer as to what
is going on.  And it may eventually be used in more than one place.

Add ANYOFHs regnode

This node is like ANYOFHb, but is used when more than one leading byte
is the same in all the matched code points.

ANYOFHb is used to avoid having to convert from UTF-8 to code point for
something that won't match.  It checks that the first byte in the UTF-8
encoded target is the desired one, thus ruling out most of the possible
code points.

But for higher code points that require longer UTF-8 sequences, many
many non-matching code points pass this filter.  Its almost 200K that it
is ineffective for for code points above 0xFFFF.

This commit creates a new node type that addresses this problem.
Instead of a single byte, it stores as many leading bytes that are the
same for all code points that match the class.  For many classes, that
will cut down the number of possible false positives by a huge amount
before having to convert to code point to make the final determination.

This regnode adds a UTF-8 string at the end.  It is still much smaller,
even in the rare worst case, than a plain ANYOF node because the maximum
string length, 15 bytes, is still shorter than the 32-byte bitmap that
is present in a plain ANYOF.  Most of the time the added string will
instead be at most 4 bytes.

regcomp.c: DTRT in av_store()

We should be increasing the ref count in the scalars.  If those aren't
needed past the end of the function doing the av_store, their ref count
can be decremented there.

Otherwise, things are inconsistent, and error prone.

find_first_differing_byte_pos

regcomp.c fix comments, white-space

One comment was just a typo, another was erroneous

Make makerel ignore other .git* files as well

Finalise perldelta and update perlhist

Update Module::CoreList for 5.31.6

regcomp.sym: Add missing commas

I don't think lack of these affects anything, but they were inconsistent

Output information on the current pull request

Output information on the current pull request

Fix the author email address on Github Actions pull requests

Like Travis CI, Github Actions use the email address used to with Github
instead of using the email address the author might have used with Git.

This patch uses the mail address from the changes itself

fix POSIX.xs under VMS

My recent commit v5.31.5-346-g116e19abbf assumed that SA_SIGINFO and
sa_sigaction would always be available, but they aren't under VMS, so
guard its use.

Update Test-Simple to CPAN version 1.302169

From Changes:

1.302169  2019-11-18 15:49:38-08:00 America/Los_Angeles

  - Update inline Object::HashBase
  - Avoid 'used only once' warnings in BEGIN and END blocks
    (James E Keenan <jkeenan@cpan.org>)

Committer: perldelta for synch-with-cpan

document that /c does nothing for s///

Another option would be to go through a deprecation cycle.

We can't just remove it, since there might be existing code that
has (the non-functional) /c.

fixes #17071

Fix qr/[...]/ for 32 bit platforms with 64bit UV's

A Size_t should have been a UV.

Fix CCHOME setting for MinGW

Clean up -Dy debugging

Commit 5d7580af4b14229eafb27db9b7a34b8b918876b4 didn't have it quite
right.

Fix tr/// for 32 bit platforms with 64bit ints

Various variables were declared wrongly to be Size_t, instead of the
needed 'UV'.

op.c: Rmv redundant line in tr/// table

The line was a relict of debugging.  I don't know if this could lead to
a bug or not, but it certainly did not belong.

Updates to perldelta

perlguts: sprintf %p now works

So recommend it instead of saying don't use it.

Set CCHOME to make op/taint.t pass

Thanks to TonyC for providing the missing piece

Add smoke support for OSX

Github Actions only get 2 CPUs

We could maybe use 3 for testing, but that's a later optimization

MSVC100FREE -> MSVC100

Skip the TTY tests since we don't have a TTY

This should fix the op/stat failure

Use Cygwin native git to fix file permissions

This should fix the porting/ related test failures

Memoize: rewrite expmod_t.t

This test script checks that cache entries expire correctly. However, it
occasionally causes smoke failures, since it's sensitive to timing and
so very slow machines may trip it up.

This commit rewrites the test script so that (hopefully) it will be
immune to timing issues.

It just repeatedly calls the memoized function, each time recording the
time just before and after, which gives a bracketed time range within
which we know the function was called. Then the previous range and the
current range can be analysed to determine whether a new or cached value
was returned, and in either case whether this was within or beyond any possible
expiry time.

Note that I removed the use Time::HiRes, as there seems to be a bug with
Memoize::Expire whereby the returned cached value gets stringified,
which can cause rounding errors if the original value was an NV.
Sticking with integers makes life easier.

perlguts: Remove stray POD characters

- double qoutes inside C<> (not used elsewhere in this doc)
- trailing ctrl-backslash

perldelta for v5.31.5-346-g116e19abbf

Document the sighandler changes.

[MERGE] fixup perl's OS signal handling

First some background:

UNIXy OSes support two types of signal handler function:

    Signal_t handler1(int sig);
    Signal_t handler3(int sig, siginfo_t *info, void *uap);

The original one-argument handler was set using the signal(2) system
call. The newer sigaction(2) system call allows either a 1-arg or
3-arg handler to be specified:

    act.sa_handler = handler1;
    sigaction(sig, act, NULL);

    act.sa_sigaction = handler3;
    act.sa_sa_flags |= SA_SIGINFO;
    sigaction(sig, act, NULL);

The current behaviour in perl core is that, in the presence of
HAS_SIGACTION and SA_SIGINFO, the signal handler type and function are
both declared as 3-arg, but perl still tells the kernel that the
supplied signal handler function takes one arg. This means that whenever
the kernel calls the handler, args 2 and 3 are whatever garbage the OS
and architecture cause them to happen to be.

Note that POSIX.xs *does* allow a 3-arg signal handler to be specified
by passing the SA_SIGINFO flag, and a couple of tests check for this.

Recently, gcc-8 has (quite reasonably) been warning that we're passing
around 3-arg function pointers where a 1-arg function pointer is
expected.

This branch fixes things up by declaring the signal handler type as
1-arg to match reality. It also introduces a new type, Siginfo_t, which
is a wrapper for those platforms which have siginfo_t, and a dummy
implementation for those which don't.

In addition it adds new explicit handler functions with a known
number of args, e.g. Perl_sighandler1() and Perl_sighandler3(), which
can be used by POSIX.xs when it wants to use a specific handler type.

It also adds a new function, Perl_perly_sighandler(), which is called by
the underlying OS signal handler to do the actual perl-level call to
$SIG{FOO}, and which has an extra arg to indicate whether it is being
called via a safe signal path or not.

Perl_csighandler(): remove forward declaration

There's a forward declaration of this function in mg.c. This should be
redundant in these days of embed.fnc and embed.h, so remove it.

Perl_perly_sighandler: re-indent some code

Fix indentation after previous commits modified scopes; also indent
some nested #if's correctly.

Whitespace-only change

Perl_perly_sighandler: combine two conditions

The branch is only taken if a number of conditions are true. Combine
them into a single if statement, with the sip test first, so that an
unnecessary call to sigaction() may be skipped if its only going to
immediately fail afterwards because sip isn't true.

Shouldn't be any change in functionality.

remove some redundant sig handler type casts

declare perl core's sig handler as 1-arg

First some background:

UNIXy OSes support two types of signal handler function:

    Signal_t handler1(int sig);
    Signal_t handler3(int sig, siginfo_t *info, void *uap);

The original one-argument handler was set using the signal(2) system
call. The newer sigaction(2) system call allows either a 1-arg or
3-arg handler to be specified:

    act.sa_handler = handler1;
    sigaction(sig, act, NULL);

    act.sa_sigaction = handler3;
    act.sa_sa_flags |= SA_SIGINFO;
    sigaction(sig, act, NULL);

The current behaviour in perl core is that, in the presence of
HAS_SIGACTION and SA_SIGINFO, the signal handler type and function are
both declared as 3-arg, but perl still tells the kernel that the
supplied signal handler function takes one arg. This means that whenever
the kernel calls the handler, args 2 and 3 are whatever garbage the OS
and architecture cause them to happen to be.

Note that POSIX.xs *does* allow a 3-arg signal handler to be specified
by passing the SA_SIGINFO flag, and a couple of tests check for this.

Recently, gcc-8 has (quite reasonably) been warning that we're passing
around 3-arg function pointers where a 1-arg function pointer is
expected.

After the groundwork laid down by the previous commits in this branch,
this commit flips things over so that the perl core now declares its
handlers and handler type as being 1-arg, thus reflecting the reality
that the core has actually being using 1-arg handlers.

This makes a whole bunch of compiler noise like this go away:

    perl.h:2825:51: warning: cast between incompatible function types
    from ‘__sighandler_t’ {aka ‘void (*)(int)’} to ‘void (*)(int,
    siginfo_t *, void *)’ {aka ‘void (*)(int,  struct <anonymous> *,
    void *)’} [-Wcast-function-type]

In theory this should make no functional difference. It might cause
3rd-party XS modules to emit compiler warnings now if they are relying
on things like Sighandler_t to represent a 3-arg function - this commit
flips it to being 1-arg.

POSIX::sigaction(): use correct sig handler

Depending on whether sigaction() is called with the SA_SIGINFO flag set,
it should be setting either a 1-arg or 3-arg signal handler for the
kernel to call back. In fact it was always passing a 3-arg handler, and
telling the kernel that it was a 1-arg handler, which means that in
1-arg handler situations, the handler was being called with args 2 and 3
containing random garbage.

Instead, use the newly-added explicit-arg handler functions, which take
the specified number of args regardless of OS / configuration.`

There's a temporary hack included in the patch because perl core is
still claiming to use 3-arg handlers while actually supplying 1-arg
ones. This will be fixed shortly and the hack removed.

add explicit 1-arg and 3-arg sig handler functions

Currently, whether the OS-level signal handler function is declared as
1-arg or 3-arg depends on the configuration. Add explicit versions of
these functions, principally so that POSIX.xs can call which version of
the handler it wants regardless of configuration: see next commit.

fix unsafe signals under exceptions

The preceding commit flagged up an existing bug, but kept old the buggy
behaviour. This commit fixes the bug. I haven't added a test, since it
seems that the test suite doesn't try with unsafe signals. But this
code:

    $SIG{USR1} = sub { $gotit++, die };
    eval { kill SIGUSR1, $$ } for 1..2;
    print "gotit=$gotit\n";

when run before erroneously gave 1, but now correctly gives 2.

Basically the code that restores the signal mask after a sig handler
dies, should do it only in a direct (unsafe) signal handler: the
deferred (safe) signal handler will have already done it. The bug was
that the inbuilt perl unsafe signal handler was being incorrectly
treated as safe. The code path via POSIX (and for which a test was added
with v5.13.9-531-gc22d665b55) *was* ok.

add a new function, Perl_perly_sighandler()

This function implements the body of what used to be Perl_sighandler(),
the latter becoming a thin wrapper round Perl_perly_sighandler().

The main reason for this change is that it allows us to add an extra
arg, 'safe' to the function without breaking backcompat. This arg
indicates whether the function is being called directly from the OS
signal handler (safe==0), or deferred via Perl_despatch_signals()
(safe==1).

This allows an infelicity in the code to be fixed - it was formerly
trying to determine the route it had been called by (and hence whether a
'safe' route) by seeing if either of the sig/uap parameters was
non-null. It turns out that this was highly dogdy, and only worked by
luck. The safe caller did indeed pass NULL args, but due to a bug
(shortly to be fixed), sometimes the kernel thinks its calling a 1-arg
sig handler when its actually calling a 3-arg one. This means that the
sig/uap args are random garbage, and happen to be non-zero only by happy
coincidence on the OS/platforms so far.

Also, it turns out that the call via Perl_csighandler() was getting it
wrong: its explicit (NULL,NULL) args made it look like a safe signal
call. This will be corrected in the next commit, but for this commit the
old wrong behaviour is preserved.

See RT #82040 for details of when/why the original dodgy 'safe' check
was
added.

add PERL_USE_3ARG_SIGHANDLER macro

There are a bunch of places in core that do

   #if defined(HAS_SIGACTION) && defined(SA_SIGINFO)

to decide whether the C signal handler function should be declared with,
and called with, 1 arg or 3 args.

This commit just adds

   #if defined(HAS_SIGACTION) && defined(SA_SIGINFO)
   #  define PERL_USE_3ARG_SIGHANDLER
   #endif

Then uses the new macro in all other places rather than checking
HAS_SIGACTION and SA_SIGINFO. Thus there is no functional change; it just
makes the code more readable.

However, it turns out that all is not well with core's use of 1-arg
versus 3-arg, and the few commits will fix this.

add Siginfo_t

From the code comments:

    This is an alias for the OS's siginfo_t, except that where the OS
    doesn't support it, declare a dummy version instead. This allows us to
    have signal handler functions which always have a Siginfo_t parameter
    regardless of platform, (and which will just be passed a NULL value
    where the OS doesn't support HAS_SIGACTION).

It doesn't actually do anything useful yet, but will shortly allow
signal handler functions to be rationalised.

regcomp.h: Fix up comment

Add ANYOFRb regnode

This is like the ANYOFR regnode added in the previous commit, but all
code points in the range it matches are known to have the same first
UTF-8 start byte.  That means it can't match UTF-8 invariant characters,
like ASCII, because the "start" byte is different on each one, so it
could only match a range of 1, and the compiler wouldn't generate this
node for that; instead using an EXACT.

Pattern matching can rule out most code points by looking at the first
character of their UTF-8 representation, before having to convert from
UTF-8.

On ASCII this rules out all but 64 2-byte UTF-8 characters from this
simple comparison.  3-byte it's up to 4096, and 4-byte, 2**18, so the
test is less effective for higher code points.

I believe that most UTF-8 patterns that otherwise would compile to
ANYOFR will instead compile to this, as I can't envision real life
applications wanting to match large single ranges.  Even the 2048
surrogates all have the same first byte.

Add ANYOFR regnode

This matches a single range of code points.  It is both faster and
smaller than other ANYOF-type nodes, requiring, after set-up, a single
subtraction and conditional branch.

The vast majority of Unicode properties match a single range (though
most of the properties likely to be used in real world applications have
more than a single range).  But things like [ij] are a single range, and
those are quite commonly encountered.  This new regnode matches them more
efficiently than a bitmap would, and doesn't require the space for one
either.

The flags field is used to store the minimum matchable start byte for
UTF-8 strings, and is ignored for non-UTF-8 targets.  This, like ANYOFH
nodes which have a similar mechanism, allows for quick weeding out of
many possible matches without having to convert the UTF-8 to its
corresponding code point.

This regnode packs the 32 bit argument with 20 bits for the minimum code
point the node matches, and 12 bits for the maximum range.  If the input
is a value outside these, it simply won't compile to this regnode,
instead going to one of the ANYOFH flavors.

ANYOFR is sufficient to match all of Unicode except for the final
(private use) 65K plane.

regcomp.c: Use variables initialized to macro results

instead of the macros.  This is in preparation for the next commit.

regexec.c: Rmv some unnecessary casts

The called macro does the cast, and this makes it more legibile

regcomp.c: Add parameter to static function

This further decouples this function from knowing details of the calling
structure, by passing this detail in.

t/re/anyof.t: Add a test

This makes sure a non-folding above-Latin1 character is tested.

Prefer EXACTish regnodes to ANYOFH nodes

ANYOFH nodes (that match code points above 255) are smaller than regular
ANYOF nodes because they don't have a 256-bit bitmap.  But the
disadvantage of them over EXACT nodes is that the characters encountered
must first be converted from UTF-8 to code point to see if they match
the ANYOFH.  (The difference is less clearcut with /i, because typically,
currently, the UTF-8 must be converted to code point anyway in order to
fold them.)  But the EXACTFish node doesn't have an inversion list to do
lookup in, and occupies less space, because it doesn't have inversion
list data attached to it.

Also there is a bug in using ANYOFH under /l, as wide character warnings
should be emitted if the locale isn't a UTF-8 one.

The reason this change hasn't been made before (by me anyway) is that
the old way avoided upgrading the pattern to UTF-8.  But having thought
about this for a long time, to match this node, the target string must
be in UTF-8 anyway, and having a UTF8ness mismatch slows down pattern
matching, as things have to be continually converted, and reconverted
after backtracking.

Add -Dy debugging of tr///, y///

t/re/anyof.t: Fix highest range tests

Previously we had infinity minus 1, but infinity should be beyond the
range, and the highest isn't infinity - 1, but the highest legal code
point.

t/re/anyof.t: Remove duplicate test

These are covered by the single code point tests.

t/re/anyof.t: Remove invalid test

One shouldn't be able to specify an infinite code point.  The tests have
the conceit that one can specify a range's upper limit as infinity, but
that is just shorthand for the range being unbounded.

re/anyof.t: Clarify failing message

When a test fails, an extra test is run to output debugging info; this
will cause the planned number of tests to be wrong, which will output an
extra, confusing message.  This adds an explanation that the number is
expected to be wrong, hence not to worry.

Allow some optimizations of qr/(?[...])/

Prior to this commit, this construct always returned an ANYOF node, even
if it could be optimized into something else.

Document SVf format

clean up quadmath_format_*() functions

This includes:

- remove them from the API

- simplify quadmath_format_single()'s interface, and rename it
  to match the new interface

fixes #17288

Remove generation and use of NonFinalFold table

With the revamping done in cc288b7a2732c37504039083ebb98241954636be, the
table of Unicode case folds that are more than a single character is no
longer used, so no need to generate it, or having it available.

mktables: Fix non-final-fold table

This wasn't generating the correct values.  It is no longer used, and
the next commit will remove it, but I wanted to get it right, in case it
is ever needed again.

Merge branch 'multi-fold' into blead

These few commits fix the code that avoids splitting a multi-character
fold across EXACTFish nodes in regex patterns

Revamp finding splittable places in /i full node

Commits 3ae8ec479bc65ef004bd856d90b82106186771d9 and
cc1ed6368d665290794d7c24d1dbeb42466e256a didn't actually work.

Tests in pat_advanced.t would have failed, except that optimizations in
the regex engine in the meantime led to the tests not actually testing
what they originally did.

I believe that this finally gets it right for non-/l.

The problem is when an EXACTFish node becomes full, you don't want to
split across a multi-char fold.  To use a fairly familiar example, we
can't split between 'ss', as that sequence matches a LATIN SMALL LETTER
SHARP S, and the way the regex engine currently works, it can't see
beyond the current node; it would see one or the other 's' but not the
sequence.  So the code backs off one character and checks if it can
split there.  If not, it repeats until it finds such a place or gets to
the beginning.  If the entire node is all 's'es, for example, there's no
good place to split.  So it gives up and takes all of them.

One thing I hadn't realized before is when there are three-character
folds, you can't split if the current position is the beginning of the
three, but also when it is the second of the three.

regcharclass.h: Add some macros

These macros will be used in a future commit, and are for
three-character folds.  regen/regcharclass*.pl are changed for this
purpose.

pat_advanced.t: Update test

This test was no longer exercising the code it once had, because ':'
doesn't go in a folded regnode.  Change to use a character that does
have a fold.

And doing so shows that something in the past broke this test.  This
branch will fix that; in the meantime make some tests TODO

S_regatom: reinitialize flags if reparsing

Sometimes we have to reparse a node.  We need to reset the flags to
avoid contamination from the first parse, where a flag got set by a
character in it that won't actually be in the reparsed version.

Revamp S_regatom() handling of non-UTF-8 folds

This accomplishes two things.  One is that prior to this commit, a
character being added to the node could set some flags before we
determine that the character won't even fit in the node.  So the flags
get set inappropriately.  This may be harmless except for performance
penalties; I don't know.

The other thing it does is to make sure 'ender' is not changed in the
loop.  A future commit with depend on that.

regcomp.c: Avoid a Copy

By reserving a few more bytes at the beginning of the loop, which will
be given back at the end anyway, we can avoid a temporary variable and a
Copy.

regcomp.c: White space, comment only

One comment was outdated.

regen/regcharclass_multi_char_folds.pl: Simplify

This creates a simply named array instead of a more complicated array
ref, so is easier to understand

regen/regcharclass_multi_char_folds.pl: Use printable char

It makes the result more legible if it uses the printable character
instead of an escape sequence when appropriate.

Although, currently, the value is re-escaped for output.  This helped
during debugging.

regen/regcharclass_multi_char_folds.pl: Fix comments

Initial Windows Github action, adapted from skaji

This supports

    * 64bit MSVC 2019 (MSVC142)
    * 64bit Mingw64 as supplied by Strawberry Perl
    * 64bit Cygwin gcc
    * 32bit MSVC 2010 (MSVC100FREE)

Characteristics

    * Only clone the repo 10 levels deep (we need only one?)
    * Parallel build on the one environment where it works (Cygwin)
    * Ready for clcache / ccache, but these need a 100% pass before
      Github saves the results to the cache

Double the number of possible SV types

As per discussion beginning in
http://nntp.perl.org/group/perl.perl5.porters/25656

regcomp.h: Fix comment

embed.fnc: Parameter is really a const

Make it so.

doop.c, op.c: Silence some compiler warnings

PATCH: gh#17218 memory leak

Indeed, a variable's ref count was not getting decremented.

win32: Add more missing wchar.h includes

Add missing wchar.h include to Win32API::File