CoreList: fix release date on v5.24.0

RC5: bump release date out for v5.24.0

corelist: fix a typo

patchlevel, perlhist: another day, another RC

RT #127855] Slowdown in m//g on COW strings

Better fix for this issue. The previous couple of commits revert an
earlier fix for this, which basically modified SvGROW or a particular
one of its callers to add 1 to the requested length to ensure that there
was space for any future COW reference count (which is stored in  spare
byte off the end of the string if SvCUR + null byte < SvLEN).

It turns out that sv_grow() already does a +1 over-allocation (added by me
with v5.19.0-442-gcbcb2a1), *except* that I made it skip the +1 if the
request size seemed to be a large power of two: with the idea being that
if someone had requested an exact big power of two then they were probably
doing something with buffers, and wouldn't want an 0x10000001 byte buffer
when they requested 0x10000000 bytes.  This was me basically being
conservative. However, I was probably too conservative: the simple test I
added just checked that bottom 8 bits were zero and if so, assumed that it
was a big buffer request. So as a side effect of this over-simple test,
something like 0x13d57f00 wouldn't be incremented to 0x13d57f01.

This is what was discovered in the original report in the the RT ticket:
strings allocated with lengths whose lower 8 bits were zero wouldn't have
space for a COW refcount, so would become much slower on things like

    while $g =~ m/0/g.

This commit improves the test so it only skips the +1 on lengths that
are an exact power of 2 and are greater than  0xfff.

test lexical $foo = "$foo"

There were some issues with this and SvGROW().
This only occured under valgrind or similar, and only when the first of
two reverts had been done - those revertd being two preceding commits.

See RT #127855.

Revert "fix #127855, in Perl_sv_setpvn() we have to overallocate to enable COW"

This reverts commit e19cb11142087974d956f263d24e146b968025d5.

This and the previous commit revert the two commits that were an original
fix for RT #127855, but which is fixed in a different way in a following
commit.  See the ticket for more details.

Revert "More generalized fix for #127855"

This reverts commit bcc9f606509ad2fad50e16f081103451b7dc49e1.

This and the next commit revert the two commits that were an original fix
for RT #127855, but which is fixed in a different way in a following
commit.  See the ticket for more details.

perldelta: update module versions

corelist: bump version past v5.22.2

prepare v5.24.0-RC4

Maintainers.pl: bump versions for threads dists

perllol: remove docs about the removed autoderef feature

corelist: updated for threads libraries

Thread-Queue: bump version (again) because content changed

threads: bump version (again) because content changed

Upgrade to Thread::Queue 3.08

Upgrade to threads::shared 1.51

Upgrade to threads 2.06

corelist: updated for File::Copy doc updates

Add cross-reference to perldata in scalar's documentation

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810156

perlrun: note the existence of find's -delete switch

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776614

Bump $File::Copy::VERSION

File::Copy: add a warning about flushing writes

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494590

perl.pod: @INC is being displayed as intended

The previous presentation looked a bit like an incomplete placeholder
expansion.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246542

Tick off 5.22.2

5.22.2 today

(Manually cherry picked from commit 72ccbefa77099a0bf1b7c2cb9f29685ed7d9938d)

Import 5.22.2's perldelta

Import 5.22.2's Module::CoreList data

trivial s/or/of/ doc patch

perlpolicy: add Sawyer X to list moderators

bump version to v5.24.0-RC3

corelist: silence deep recursion warning with %version

Remove some data detritus from CoreList

Document exports policy within POSIX

Correct lround situation comment in POSIX

bump perl version to v5.24.0-RC2

corelist: update Time::HiRes for v5.24.0

Synchronize with CPAN Time-HiRes 1.9733

lib/perl5db.pl: Fix pod error.

Apple Xcode / clang version updates and additions

darwin (OS X) hints comments alignment

(preparing for the next change)

Time-HiRes version bump

[PATCH] Time-Hires: Fix declaration-after-statement error with darwin threads

rt #113856: the flag -Werror=declaration-after-statement is seemingly
not working for clang (in OS X, not yet tested elsewhere), but working
as intended for gcc.  Since the system cc for OS X is clang (via Apple),
this failure to fail has been masked.

To restate: without this patch the Time-HiRes does not build in OS X
with gcc under usethreads.

Regenerate Configure and related parts after backports

perl5.git is now in sync with metaconfig.git commit
7c34fa4e8142642c6e2978f0307e925898465f58

Bring Configure back into sync again with meta

Work done at the QAH in Rugby.
Multi-thanks to Aaron for helping out here. You're doing a great job!

Allow Encode to be built on static perls

Previously there were build failures because cp1252 was defined both
in the default set of encodings an in the byte set.

Revert "document that sigs in future may not populate @_"

This reverts commit 19d6c3854e96d89bf4dc2d874df433beac27ee8b.

Fix some pod errors

These were discovered while testing the Pod::Checker that is intended to
be used in 5.25.

[perl #127936] fix typo

perldelta for ab462c7d2d

[perl #127894] ensure alignbytes is correct for -Dusequadmath

Correct typo in JJORE's name in todo.pod.

Avoid passing non-literal to format function

This avoids the following error, reported by Jitka Plesníková
<jplesnik@redhat.com> in a test of RC1:

op.c: In function 'Perl_ck_ftst':
op.c:9754:58: error: format not a string literal and no format arguments [-Werror=format-security]
                 Perl_warner(aTHX_ packWARN(WARN_SYNTAX), array_passed_to_stat);

In addition, the string in question is now made const.

document that sigs in future may not populate @_

Give people a heads up that in the next major perl release, subroutine
signatures may no longer populate @_ by default.

See http://nntp.perl.org/group/perl.perl5.porters/235332.

perldelta: Remove error/warning explanations

Only the text of these should be present in a delta, with a link to the
full explanation.  Most of perldelta conformed to this, but not all.

perldelta: Add some C<>

perldelta: Clarifications, corrections, wordsmithing

I also removed one instance of a 5.23-only bug, which isn't relevant to
a dot zero delta

Add perldelta for d9fc04ee

perldelta: IO-Compress is a dist, no link possible

perldelta: generate the module update section

perldelta: various fixes

 * behaviour -> behavior
 * =over -> =over 4
 * Add =items for consistency
 * Capitalization fixes

perldelta: Fix typo

perldelta: Revise wording

Some of this was suggested by Jarkko Hietaniemi

perldelta: Remove typo extra '/'

This fixes the 5.24 part of [perl #127899].

perldelta: minor tweak to fix awkward prose

(Thanks, Ed Avis!)

patchlevel: we are now RC1

remove the v5.23.x perldeltas

perlpolicy: update the supported versions for v5.24 on

perlhist: add v5.24.0 data

corelist: set a (tentative) release date for 5.24.0

fix IO::Handle documentation mangled by a manually applied patch

perllocale: Unicode has changed their data; fix references

We say something here that is no longer true; update it.

perldelta: Some minor fixes.

This includes deleting some bug fixes for things introduced in the 5.23
series, and so not relevant to a dot zero perldelta

pod/perldelta: Fixes to pedantic failures

perldelta: Add note about recent doc change

Merge branch 'release-5.24' into blead

This commit is just prep, turning blead into the branch from which
v5.24.0 will be released, after suitable testing.

CoreList: update for v5.24.0

fix versions of generated perldelta

put perl5240delta into place

regen META.json for v5.24.0-RC

regen: B::Op_private and uconfig.h

version bump: this is now v5.24.0-RC0!

perldelta: merge in perl5239delta

perldelta: remove unneeded entries, do more merge and sort

perldelta: merge in changes from perl5238delta

perldelta: merge in changes from perl5237delta

perldelta: merge in changes from perl5236delta

perldelta: merge in changes from perl5235delta

perldelta: merge in changes from perl5234delta

perldelta: merge in changes from perl5233delta

perldelta: merge in changes from perl5232delta

perldelta: merge in changes from perl5231delta

perldelta: bootstrap perl5240delta with perl5230delta

Add 5.22.2-RC1 epigraph

5.22.2-RC1 today

PATCH: [perl #127708] segfault in "$!" in threads

This was showing up on Darwin because its setlocale is particularly not
thread safe.  But the problem is more generic.  Using locales just
isn't a good idea in a threaded application, as locales are
process-wide, not thread-specific.  Calling setlocale() changes the
locale of all threads at the same time.  Further the return of
setlocale() is a pointer to internal storage.  If you call setlocale()
just to learn what it currently is without actually changing the locale,
there is no guarantee that another thread won't interrupt your thread,
switching the locale to something else before you've had a chance to
copy it somewhere else for safekeeping, and the internal storage may
have been freed during that interruption, leading to things like
segfaults.

This is a problem that has been around in the locale handling code for a
long time.  I don't know why it hasn't shown up before, or maybe it has
and is not reproducible because it's timing dependent, and so any
problems didn't have tickets written for them, or were rejected as not
reproducible.

But the problem has been made worse in recent releases.  Only fairly
recently has perl changed so this problem can occur in programs that
don't use locale explicitly: ones that don't 'use locale' nor call
setlocale().  This ticket is for such a program that gets a
locale-related segfault, without ever touching locales itself.

I have done an audit of the perl source, looking for all such
occurrences, and this patch fixes all of them that I found.  The only
other ones, besides "$!", is in converting to/from UTF-8 in cygwin.c.
In all such cases, perl briefly switches the locale, does an operation,
then switches back.  The solution here is to add mutexes to make these
areas of code uninterruptible critical sections, so that they can rely
on having the locale be what they expect it to be during the entirety of
the operation, and can't have a setlocale() from another thread free
internal storage.  But this is not a general solution.  A thread
executing these sections can interrupt some other thread doing a
setlocale() and zap that.  However, we have long cautioned against doing
setlocales() in a thread, and that caution was strengthened in a commit
made yesterday, fc82b82ef4784a38877f35f56ee16f14934460ce.

The current commit should make safe all threaded programs that don't use
locales explicitly.

It's too close to the 5.24 release to do the rearchitecting required for
a general solution.  That would involve adding more critical sections.

POSIX 2008 introduced new locale handling functions that are
thread-safe, and affect only a single thread, and don't require mutexes.
The ultimate solution would be to use those tools where available, and
to hide from the outer code which set is being used.  Thus, perl would
be thread-safe on such platforms, while remaining problematic on older
ones, though fixed so segfaults wouldn't occur.  Tony Cook believes we
could emulate the newer behavior on all platforms at a significant
performance penalty.  I think this would require a lot of code, and
suspect there would be glitches in it for XS code.  But he may have
some ideas about how to do it simply.  In any case, this has to wait
until post 5.24.

Three other notes:

It seems to me that the cygwin code could be replaced by equivalent code
that doesn't use locales at all.  The comments in the source seem to
even indicate that.  I'll look into doing this in 5.25.

Another possible reason that this hasn't shown up in earlier perls is
that the problems may have been entirely affecting I/O operations and
there are already mutexes involving I/O, and so those could be
inadvertently protecting from, or at least minimizing, the problems
found here.  I haven't investigated to verify this.

This commit doesn't add a test.  I am asking on p5p for assistance in
writing one

Add locale mutex

This adds a new mutex for use in the next commit for use with locale
handling.

move perf test from re/pat.t to re/speed.t

These days we generally put re tests which rely on timing in a separate
file, t/re/speed.t; move a recently-added test there.

new perf test in pat.t: avoid timing failure

A new performance test in re/pat.t added by v5.23.9-58-gd14d585 could
occasionally fails to a timing issue. It was checking that the the
test took less than 1 sec to run; but since the clock usually has a
granularity of 1 sec, it could fail if the test ran over a tick boundary.

Change the condition to <= 1 sec, and increase the time the test takes on
a bad perl - it was taking 4sec on my system; it now takes about 14sec,
so there's less chance of a bad perl passing.