t/thread_it.pl: Increase stack size for AIX

This is enough to get the smoker to pass t/re/pat_thr.t

Update release manager's guide

PATCH: [perl #126261: Assertion failure on missing [ in qr//

This is the result of the regex compiler creating a temporary buffer to
parse a portion of the input pattern, and then when an error or warning
occurs in that buffer, trying to use addresses both inside it and the
original pattern.

The solution here is a general one, that confines the heavy lifting to
one macro, plus a little setup and tear-down around the use of the
temporary buffer.  The comments in the code detail how we relate the
address of the error in the temporary back to the parallel address in
the input pattern.

regcomp.c: update RExC_start when parsing outside input

I noticed this while code reading.  In places, regcomp parses not the
input pattern but a temporary buffer it constructs, based on that input
pattern.  RExC_start should be updated so it always is pointing to the
same buffer as the parse pointer; otherwise segfaults can happen.

I have no idea how one currently can get into the situation this
protects against, so there are no tests added.

regcomp.c: Add a stable pattern end pointer.

RExC_end is set sometimes during pattern compilation to perhaps another
string in memory.  Messages are output based on the original string, so
create an end pointer that is in terms of that original string,
otherwise could get segfaults.

t/lib/warnings/regcomp: Fix typo in comment

regcomp.c: Use macro instead of recalculating

There is a macro that does the job that this code does.  Use it.

regcomp.c: Move calculations to common macro

This consolidates identical calculations into a single place, which
makes things easier to maintain.

Probably the reason they previously were dispersed, is because now the
common macro has to evaluate the same expression more than once.  Since
the macro is used to return a list, it can't be turned into a single
statement.

Any decent optimizing compiler will extract the common subexpressions
and evaluate them just once.  But even if not, the macro is called only
in the event of a fatal error (in which case speed is not important), or
to raise a warning, which we expect to be rare, and the extra work is
negligible in comparison with what is needed to output the message.

regcomp.h: reword some comments

regcomp.c: Make some params to a static fcn const

This is just acting on the TODO comment.

regcomp.c: Add 2 basic assertions

These should be true because an SV* should always have a trailing NUL,
but a lot of things in this code depend on it.  It's worthwhile to point
that out; I wasn't sure it was true until I investigated.  And an
assert() makes sure it is really true

pp_hot.c: Add assertion

This will make the cause of any future failures more clear.

perlapi: Clarify 'string' vs. buffer

A string strictly is NUL terminated, but our terminology is lax

utf8.h: Add 2 assertions

This makes sure in DEBUGGING builds that the macro is called correctly.

Controlled demolition, CoreList is 5.20151220

Deprecate to_utf8_case()

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

Bump the perl version in various places for 5.23.7

Create new perldelta.pod for v5.23.7

Updated release schedule

Updated Porting/epigraphs.pod for v5.23.6

add new release to perlhist

Update perldelta with additional module updates

Update perldelta with Module::CoreList version bump

Update Module::CoreList from 5.23.6

Update perldelta to near-final state

perldelta for case changing on caseless language

perldelta for -Dr fix

Update perldelta

This commit adds various release notes covering:

* module updates
* documentation updates
* some bug fixes and internal changes

Correct perldelta typo

Add alternate email address for dagolden to checkAUTHORS.pl

perldelta for 18371617dfb (B::Deparse)

Do not define invlistEQ in the re extension.

Because it's already defined in regcomp.c and the VMS build was
failing with a linker error (multiply-defined symbol).

regcomp.c: Skip some work

We can optimize ANYOF nodes that are equivalent to POSIX character
classes.  Discovering if they are equivalent takes work, which can be
skipped with a simple test that will rule out many run-of-the-mill
character classes.

regcomp.c: White space only

Indent a section of code in preparation for the next commit which will
make it into a block.

regcomp.c: Add comments

mktables: Add "$0:" to its first output

So in a make, it is abundantly clear where the messages are coming from

regcomp.c: Silence uninit compiler warning

This shouldn't actually happen, and g++ under -O0 didn't flag it, but
gcc under -O2 does, so initialize to an illegal value

regcomp.c: Remove outdated comments

These were invalidated by commit
709be747a32edc503b4645d9c5396bd4b40100d2

Fix -Dr problems.

Commits 108316fb65dc7243a1c5d87b4b29068b7d62d32e
and 5e85fd899767ba3003766fc9289c0ee2d8427d10
broke -Dr output in rare cases.

perldelta for 572cd850,406d5545 (signbit)

perldelta for the hexfp %a fixes.

perldelta for 3118d7d,74c6ce8,1f02ab1 (ppc64el fp)

perldelta for 68bcb86 (openindiana: useshrplib for all solaris)

Configure: notes on the m68881 extended precision format

Double-double implementations differ.

Optimize some qr/[...]/ classes

Bracketed character classes generally generate an ANYOF-type regnode,
which consists of a bitmap for the lower code points, and an inversion
list or swash to handle ones not in the bitmap.  They take up more
memory than other regnode types.  There are already some optimizations
that use a smaller and/or faster regnode instead.  For example, some
people prefer not to use a backslash to escape metacharacters, instead
writing something like /abc[.]def/.  This has for some time generated
the same thing as /abc\.def/ does, namely a single EXACT node, which is
both smaller and faster than an ANYOF node in the middle of two EXACT
nodes.

This commit adds some optimizations that hadn't been done previously.
Now things like /[\p{Word}]/ will optimize to \w, for example.  I had
not done this before, because my tests had shown very little performance
difference, but I had added most of the code to regcomp.c so it wouldn't
get lost, #ifdef'd out.

It turns out that I hadn't tested on code points above the bitmap, which
with this commit have a small, but appreciable speed up in matching, so
this commit enables and finishes that code.

Prior to this commit, things like /[[:word:]]/ were optimized to \w, but
things like /[_[:word:]]/ were not.  This commit fixes that.

If the following command is run on a perl compiled with -O2 and no
DEBUGGING:

    blead Porting/bench.pl --raw --benchfile=charclass_perf --perlargs=-Ilib /path_to_prior_perl="before this commit" /path_to_this_perl=after

and the file 'charclass_perf' contains
    [
        'regex::charclass::ascii' => {
            desc    => 'charclass, ascii range',
            setup   => 'my $a = qr/[\p{Word}]/',
            code    => '"A" =~ $a'
        },
        'regex::charclass::upper_latin1' => {
            desc    => 'charclass, upper latin1 range',
            setup   => 'my $a = qr/[\p{Word}]/',
            code    => '"\x{e0}" =~ $a'
        },
        'regex::charclass::above_latin1' => {
            desc    => 'charclass, above latin1 range',
            setup   => 'my $a = qr/[\p{Word}]/',
            code    => '"\x{100}" =~ $a'
        },
        'regex::charclass::high_Unicode' => {
            desc    => 'charclass, high Unicode code point',
            setup   => 'my $a = qr/[\p{Word}]/',
            code    => '"\x{10FFFF}" =~ $a'
        },
    ];

the following results are obtained:

The numbers represent raw counts per loop iteration.

regex::charclass::above_latin1
charclass, above latin1 range

       before this commit    after
       ------------------ --------
    Ir             3344.0   2888.0
    Dr              971.0    855.0
    Dw              604.0    541.0
  COND              575.0    504.0
   IND               25.0     25.0

COND_m               11.0     10.7
 IND_m               10.0     10.0

 Ir_m1                8.9      6.0
 Dr_m1                3.0      3.2
 Dw_m1                1.5      1.4

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

regex::charclass::ascii
charclass, ascii range

       before this commit    after
       ------------------ --------
    Ir             2661.0   2649.0
    Dr              798.0    795.0
    Dw              516.0    517.0
  COND              467.0    465.0
   IND               23.0     23.0

COND_m               10.0      8.8
 IND_m               10.0     10.0

 Ir_m1                7.9      0.0
 Dr_m1                2.9      3.1
 Dw_m1                1.3      1.3

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

regex::charclass::high_Unicode
charclass, high Unicode code point

       before this commit    after
       ------------------ --------
    Ir             3344.0   2888.0
    Dr              971.0    855.0
    Dw              604.0    541.0
  COND              575.0    504.0
   IND               25.0     25.0

COND_m               11.0     10.7
 IND_m               10.0     10.0

 Ir_m1                8.9      6.0
 Dr_m1                3.0      3.2
 Dw_m1                1.5      1.4

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

regex::charclass::upper_latin1
charclass, upper latin1 range

       before this commit    after
       ------------------ --------
    Ir             2661.0   2651.0
    Dr              798.0    796.0
    Dw              516.0    517.0
  COND              467.0    466.0
   IND               23.0     23.0

COND_m               11.0      8.8
 IND_m               10.0     10.0

 Ir_m1                7.9      0.0
 Dr_m1                2.9      3.3
 Dw_m1                1.5      1.2

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

regcomp.h: Add comments

regex matching: Don't do unnecessary work

This commit sets a flag at pattern compilation time to indicate if
a rare case is present that requires special handling, so that that
handling can be avoided unless necessary.

regcomp.h: Renumber 2 flag bits

This changes the spare bit to be adjacent to the LOC_FOLD bit, in
preparation for the next commit, which will use that bit for a
LOC_FOLD-related use.

regex: Free a ANYOF node bit

This is done by combining 2 mutually exclusive bits into one.  I hadn't
seen this possibility before because the name of one of them misled me.
It also misled me into turning on one that flag unnecessarily, and to
miss opportunities to not have to create a swash at runtime.  This
commit corrects those things as well.

regcomp.c: Move comments adjacent to their object

regcomp.c: Try simplifications in some qr/[...]/d

Characters in a bracketed character class can come from a bunch of
sources, all bundled together.  Some things under /d match only when the
target string is UTF-8; some match only when it isn't UTF-8.  Other
sources may introduce ones that match regardless.  It may be that some
things are specified as conditionally matching from one source, and as
unconditionally matching from another.  We can subtract the
unconditionals from the conditionals, leaving a simpler set of things
that must be conditionally matched.  In some cases, the conditional set
may go to zero, allowing other optimizations to happen that otherwise
couldn't.  An example is

    qr/[\W\xAB]/

which before this commit compiled to:

    ANYOFD[^0-9A-Z_a-z\x{80}-\x{AA}\x{AC}-\x{FF}][{non-utf8-latin1-all}
    {utf8}0080-00A9 00AC-00B4 00B6-00B9 00BB-00BF 00D7 00F7
    02C2-02C5...] (12)

and after it, compiles to

    ANYOFD[^0-9A-Z_a-z\x{AA}\x{B5}\x{BA}\x{C0}-\x{D6}\x{D8}-\x{F6}
    \x{F8}-\x{FF}][{non-utf8-latin1-all}{utf8}02C2-02C5...] (12)

Notice that the {utf8} component has been stripped of everything below
256.  That means no swash has to be created at runtime when matching
code points below 256, unlike the case before this commit.

A starker example, though unlikely in real life except in
machine-generated code, is

    qr/[\w\W]/

Before this commit, it would generate:

    ANYOFD[\x{00}-\x{7F}][{non-utf8-latin1-all}{above_bitmap_all}
    {utf8}0080-00FF]

and afterwards, simply:

    SANY

regcomp.c: Change variable name to be clearer

This name confused me, and led to suboptimal code.  The new name is more
cumbersome, but won't confuse (at least it won't confuse me).

Configure: grep -q is not portable

It does not work in SysV (solaris) or old BSD greps.

Revert "Upgrade Socket from 2.020 to 2.021"

This reverts commit 0bd66ca801c5fb84ee6a8feeb8114f0d8248029f.

Worked for me, but Jenkins isn't happy :-(

Update META.yml following commit 0d99ea0387

Upgrade Term-ANSIColor from 4.03 to 4.04

Upgrade Socket from 2.020 to 2.021

Blead customizations are now assimilated.

Upgrade CPAN-Meta-YAML from 0.017-TRIAL to 0.018

Upgrade CPAN-Meta-Requirements from 2.133 to 2.140

perldelta for e3962106e93f

[perl #126240] use -DPERL_USE_SAFE_PUTENV where possible on OS X

On threaded builds on OS X, libSystem registers atfork handlers that
call setenv(), which internally modifies members of environ[], setting
them to malloc()ed blocks.

In some cases Perl_my_setenv() reallocates environ[] using
safesysmalloc(), which under debugging builds adds a tracking header,
and if perl_destruct() sees that environ[] has been reallocated, frees
it with safesysfree().

When these combine, perl attempts to free the malloc()ed block with
safesysfree(), which attempts to access the tracking header, causing
an invalid access in tools like valgrind, or a "free from wrong pool"
error, since the header contains unrelated data.

Avoid this mess by letting libc manage environ[] if unsetenv() is
available.

perldelta for dc9ef9989ca4

document save_gp() and the GVf_INTRO flag

[perl #124097] don't let the GPs be removed out from under pp_sort

pp_sort() saves the SV pointers for *a and *b, if the sort block
cleared *a or *b the GP, which the pointer is stored would be freed
and the save stack processing would try to write to freed memory.

Make sure the GP lasts at least long enough for the SV slots to be
restored.  This doesn't attempt to restore *a or *b, the user chose
to clear them.

Explicitly build the shared Perl library in Solaris and variants.

Symptom of failure: in openindiana "make" fails:

...
./perl -Ilib -f pod/buildtoc -q
Can't load 'lib/auto/re/re.so' for module re: ld.so.1: perl: fatal:
relocation error: file lib/auto/re/re.so: symbol PL_localizing:
referenced symbol not found at lib/XSLoader.pm line 71.
  at lib/re.pm line 88.
...

Running the above command with 'env LD_DEBUG=files ...' shows that
there are many other symbol lookup failures, the one above is just
the last one before bailing.

If configured explicitly with -Duseshrplib, openindiana build succeeds.

Curiously, while the hints/solaris_2.sh (which openindiana uses) does
not specify useshrplib, Oracle/Sun builds/has been building their perl
with useshrplib since Perl 5.6.1 or thereabouts (source: Alan Burlison).
Using shared libraries is strongly recommended in Solaris in general
(source: the same).

Tested in:
- Solaris 5.10/i386 with solstudio 12.2 and gcc 4.8.0
- Solaris 5.10/sparc with solarisstudio 12.3 and gcc 4.9.2
- OpenIndiana 5.11/i386 with solarisstudio 12.3 and gcc 4.5.0

perlpodspec: fix typo

Deprecate wide chars in logical string ops

See thread starting at
http://nntp.perl.org/group/perl.perl5.porters/227698

Ricardo Signes provided the perldelta and perldiag text.

Change deprecation warning text

The old text used the passive voice.  No 5.23 release has been made with
the old text, so no perldelta changes are needed.

perldiag.pod: Correctly alphabetize an entry

doop.c: Fix typo in comment

Mark the Perldoc.pm as customized

amigaos4: cpan/Pod-Perldoc: add pager preferences

Upstreamed: https://rt.cpan.org/Ticket/Display.html?id=110368

amigaos4: use the AmigaOS pager

encoding-warnings: Skip tests on EBCDIC

This module uses the deprecated $^ENCODING mechanism, which doesn't work
right on EBCDIC.

perldelta: Fix typo leading to broken link

Fix use of == to compare strings in perlref.pod

perldelta for cd3393cf71a2

New "Trailingcomma" feature for Data::Dumper.

Merge branch 'data-dumper-trailingcomma' into blead

This branch adds a "Trailingcomma" option to Data::Dumper, as suggested by
RT#126813. It also refactors the XS implementation of Data::Dumper somewhat,
in a way that made it much easier to add this feature (and will hopefull
have the same effect for future such feature additions).

Data::Dumper: add Trailingcomma option

This is as suggested in RT#126813.

The refactoring to use a structure for the style variables has now paid off:
the additional variable is mentioned only where it's directly relevant,
rather than needing to be passed explicitly to every recursive call.

Data::Dumper: replace pointer with local variable

The recursive dumping function uses a "level" variable to keep track of how
deep in the data structure it is. Previously, this variable was allocated on
the stack at the top level, and a pointer to that stack variable was passed
to each recursive invocation. Each recursive step was careful to increment
and decrement the pointed-to value at the right time. The consequence of
this approach is that understanding what's going involves mentally tracking
this state throughout the entire thousand-line function.

This change therefore replaces that pointer-to-mutable-int with a plain int
parameter; when the dumper invokes itself recursively, it simply adds one to
the level as needed. This seems much simpler to me.

This may also be faster: not only is the pointer indirection removed for
accesses to the variable, but on platforms where pointers are wider than I32
(including typical 64-bit systems), less memory is used on the stack for the
call frames.

Data::Dumper: move sortkeys setting into style struct

On Perl 5.6, there is no sortsv() function available to XS code, so
Data::Dumper used a Perl helper function. The name of that helper function
was allocated as a (mortal) SV, but that was done lazily, the first time the
helper was needed. This meant that the "sortkeys" C variable was mutable,
and therefore it couldn't be easily moved to the struct.

I think it's a better trade-off to allocate the SV in all cases under 5.6:
when dumping a data structure containing no hashes, we now allocate this SV
unnecessarily, but we save an extra pointer on the stack in every recursive
call frame.

In addition, Data::Dumper doesn't currently work on 5.6 as far as I can tell,
so this change certainly doesn't make anything any worse. I've nonetheless
attempted to restore 5.6 compatibility in this narrow area surrounding the
sortkeys option: in particular, a sortsv() call appeared in code that was
compiled under 5.6, but has now been moved to a block that's compiled only
under later Perls. I haven't been able to test this change on 5.6, though.

Data::Dumper: reorder elements of style struct

Putting all the pointers and pointer-sized integers together at the start of
the struct reduces the amount of wasted space on platforms where pointers
are wider than ints. In particular, this should reduce the size of the style
struct by eight bytes on typical 64-bit configurations.

This could have been part of the previous commit, but having the order of
the struct's elements match the subroutine arguments that it replaced made
it easier to review that change for correctness.

Data::Dumper: refactor XS implementation

There are over a dozen variables that control the details of how Data::Dumper
generates output, almost all of which remain unchanged while dumping a single
set of objects. The previous implementation passed each of those control
variables as a separate argument to the recursive DD_dump() function, which
meant that DD_dump() took over two dozen parameters. This is already far
beyond what seems reasonable, and the problem will only get worse in future
as Data::Dumper acquires more features.

This refactoring therefore extracts most of those style variables into a
struct, and passes it to the recursive calls as a pointer-to-const. This is
clearly of huge benefit for maintainability. In addition, it seems plausible
that it will make dumping slightly faster, especially for deeply-nested data
structures: requiring every recursive call to have its own copy of
them on the stack meant that every call frame would take up more than a
single cache line of stack space even on 32-bit platforms. Putting them all
in a single struct means that this space is used only once per dump instead.

"If you have a procedure with 10 parameters, you probably missed some."
—Alan Perlis, Epigrams on Programming, ACM SIGPLAN Notices 17 (9), September
1982, pp. 7–13. http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

lib/meta_notation: Fix so C1 controls are escaped

Prior to this commit the meta notation for C1 controls included raw C0
controls.

lib/meta_notation.pm: Fix typo in comment

perlgit: Keep verbatim lines within 79 columns

Fix -Dr output

Before this commit, the debug output of a compiled regular expression
was wrong in some cases for /d bracketed character classes.

For example,

    qr/[\W\xAB]/

was displayed as compiling to:

    ANYOFD[^0-9A-Z_a-z\x{80}-\x{AA}\x{AC}-\x{FF}][{non-utf8-latin1-all}
    {utf8}00AB 02C2-02C5...] (12)

instead of the correct:

    ANYOFD[^0-9A-Z_a-z\x{80}-\x{AA}\x{AC}-\x{FF}][{non-utf8-latin1-all}
    {utf8}0080-00A9 00AC-00B4 00B6-00B9 00BB-00BF 00D7 00F7 02C2-02C5
    ...] (12)

This was due to to the fact that the expression inside the first set of
square brackets was complemented, and the remainder was not complemented
back for display in the second set.

We have no tests for the debugging output, as there are no guarantees of
stability as to what gets output.  I also noticed a potential memory
leak, which this corrects.  But there are others in debugging, so I
didn't add a test for it.

Mention the clang thread safety analysis.

add note about scope in strict docs

The strict pragma only effects the current file or block scope, but we
never mention that in the docs. Thanks KES for reporting this.

Merge branch 'mixed-endian-double-double' into blead

infnan: NaN payload for mixed endian double-doubles

Configure: infnan for mixed-endian double-double

Configure: mixed-endian double-doubles

The ppc64el is the first seen little-endian double-double (and also
the first little-endian ppc), but it turns out its little-endianness
is mixed: the doubles are still in big-endian order.  Configure was
expecting wrongly a fully byte-reversed double-double.

Therefore extend the long double format detection to cover all the
(double-double) permutations, though the formats of five and eight
are rather unlikely (based on current platforms using double-double).

Configure: cannot trust the bytes after the 80-bit fp

They can be zero, they can be garbage.

pp_padav, pp_padhv whitespace only

There was some bizarre indentation (1,2 or 3-space indents)

perldelta for 0fd86aa72aab

bump $utf8::VERSION for the utf8_heavy.pl fix

perldelta for 093d5aa02ee8

perldelta for d3b9036e206e