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

perldelta for e8c18a8486f7

perldelta for 2efdfb1e6cf6

perldelta for 8f8d807bf58b

5.22.1 is done

Import 5.22.1 perldelta

Add 5.22.1 epigraph

5.22.1 today

5.22.1 today - update Module::CoreList

avoid leaks when calling mg_set() in leave_scope()

In leave_scope() in places like SAVEt_SV, it does stuff like

    if (SvSMAGICAL(...))
        mg_set(...)
    SvREFCNT_dec_NN(ARG0_SV)

If mg_set() dies (e.g. it calls STORE() and STORE() dies), then ARG0_SV
would leak. Fix this by putting ARG0_SV back in the save stack in this
case.

A similar thing applies to SAVEt_AV and SAVEt_HV, but I couldn't
think of a simple test for those, as tied array and hashes don't have
set magic (just RMG).

Also, SAVEt_AV and SAVEt_HV share a lot of common code, so I made
SAVEt_HV goto into the SAVEt_AV code block for the common part.

utf8.c: Fix EBCDIC double translation

In Perl_uvoffuni_to_utf8_flags(), the input is a Unicode, not native,
code point.  But in ba6ed43c6aca7f1ff5a1b82062faa3e1c33c0582, I used a
macro that assumes the input is native.

Suppress overflow warning in bop.t.

There is a constant designed to exercise the limits of a 64-bit
integer that causes an overflow when IVs are 32 bits.  The warning
happens at compile time and we don't know yet that we will never
execute the 64-bit path at run time.

hexfp: all ppc/powerpc-ld linux tailbits difference in exp(1)

(not just linux-ppc64-ld)

Not a regression from 5.22.0.

Skip casing for high code points

As discussed in the previous commit, most code points in Unicode
don't change if upper-, or lower-cased, etc.  In fact as of Unicode
v8.0, 93% of the available code points are above the highest one that
does change.

This commit skips trying to case these 93%.  A regen/ script keeps track
of the max changing one in the current Unicode release, and skips casing
for the higher ones.  Thus currently, casing emoji will be skipped.

Together with the previous commits that dealt with casing, the potential
for huge memory requirements for the swash hashes for casing are
severely limited.

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

    blead Porting/bench.pl --raw --perlargs="-Ilib -X" --benchfile=plane1_case_perf /path_to_prior_perl=before_this_commit /path_to_new_perl=after

and the file 'plane1_case_perf' contains

    [
        'string::casing::emoji' => {
            desc    => 'yes swash vs no swash',
            setup   => 'my $a = "\x{1F570}"',  # MANTELPIECE CLOCK
            code    => 'uc($a)'
        },
    ];

the following results are obtained:

The numbers represent raw counts per loop iteration.

string::casing::emoji
yes swash vs no swash

       before_this_commit    after
       ------------------ --------
    Ir              981.0    306.0
    Dr              228.0     94.0
    Dw              100.0     45.0
  COND              137.0     49.0
   IND                7.0      4.0

COND_m                5.5      0.0
 IND_m                4.0      2.0

 Ir_m1                0.1     -0.1
 Dr_m1                0.0      0.0
 Dw_m1                0.0      0.0

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

Skip casing for some non-cased scripts

Characters whose upper, lower, title, or fold case differ from the
character itself amount to just 1.5% of the assigned Unicode characters,
and this percentage falls with each new Unicode release, as almost all
cased scripts have already been encoded.  But a lot of code is written
assuming a cased language, such as calling uc() or lcfirst(), or doing
qr//i.  When such code is run on a non-cased language, the work expended
in doing the casing is wasted.  And casing is expensive.  But finding
out if a character is cased or not is nearly as expensive, so one might
as well just do the casing.

However, the Unicode code space is organized so that there are some long
stretches of contiguous code points that aren't cased.  By adding tests
to see if the input code point is in just a few of these ranges, we can
quickly rule casing out for most of the non-cased scripts that are of
commercial use today, at essentially no expense to handling the more
common cased scripts.  Testing for just 3 ranges in Plane 0 of Unicode
(where most of the code points in common use today reside) allows us to
skip doing casing for more than 82% of code points in the plane,
including the following languages: Arabic, Chinese, Hebrew, Japanese,
Korean, Thai, and the major scripts of India.  No longer is a swash
generated when trying to case one of these, so runtime memory usage is
decreased.

(It should be noted that some of these languages have characters
scattered in other areas, because the original allocation for them
turned out to be not large enough.  When changing the case of these
other characters, the lookups won't be skippped.  But that original
allocation included all or nearly all the characters in current common
use, so these other characters are comparatively rare.)

The comments in the code indicate some candidate non-cased ranges that I
chose not to treat specially at this time.  The next commit will address
planes above Plane 0.

When this command is run on a perl compiled with -O2, no DEBUGGING:

    blead Porting/bench.pl --perlargs="-Ilib -X" --benchfile=plane0_casing_perf /path_to_prior_perl=before_this_commit /path_to_new_perl=after

and file 'plane0_casing_perf' contains
    [
        'string::casing::greek' => {
            desc    => 'should be no change',
            setup   => 'my $a = "\x{3B1}"',  # GREEK SMALL LETTER ALPHA
            code    => 'uc($a)'
        },
        'string::casing::hebrew' => {
            desc    => 'yes swash vs no swash',
            setup   => 'my $a = "\x{5D0}"',  # HEBREW LETTER ALEF
            code    => 'uc($a)'
        },
        'string::casing::cjk' => {
            desc    => 'yes swash vs no swash',
            setup   => 'my $a = "\x{4E01}"',
            code    => 'uc($a)'
        },
        'string::casing::korean' => {
            desc    => 'yes swash vs no swash',
            setup   => 'my $a = "\x{AC00}"',
            code    => 'uc($a)'
        },
    ];

These are the results:

The numbers represent raw counts per loop iteration.

string::casing::cjk
yes swash vs no swash

       before_this_commit    after
       ------------------ --------
    Ir              931.0    300.0
    Dr              217.0     93.0
    Dw               94.0     45.0
  COND              129.0     48.0
   IND                7.0      4.0

COND_m                1.5      0.0
 IND_m                4.0      2.0

 Ir_m1                0.1      0.0
 Dr_m1                0.0      0.0
 Dw_m1                0.0      0.0

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

string::casing::greek
should be no change

       before_this_commit    after
       ------------------ --------
    Ir              946.0    920.0
    Dr              218.0    220.0
    Dw              100.0    100.0
  COND              127.0    121.0
   IND                6.0      8.0

COND_m                0.5      1.3
 IND_m                2.0      2.0

 Ir_m1                0.1      0.0
 Dr_m1                0.0      0.0
 Dw_m1                0.0      0.0

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

string::casing::hebrew
yes swash vs no swash

       before_this_commit    after
       ------------------ --------
    Ir              928.0    290.0
    Dr              224.0     92.0
    Dw              100.0     45.0
  COND              129.0     46.0
   IND                6.0      4.0

COND_m                0.5      0.0
 IND_m                2.0      2.0

 Ir_m1                0.1      0.0
 Dr_m1                0.0      0.0
 Dw_m1                0.0      0.0

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

string::casing::korean
yes swash vs no swash

       before_this_commit    after
       ------------------ --------
    Ir              953.0    307.6
    Dr              224.0     93.0
    Dw              100.0     45.0
  COND              131.0     50.9
   IND                7.0      4.0

COND_m                1.5      0.0
 IND_m                4.0      2.0

 Ir_m1                0.1      0.0
 Dr_m1                0.0      0.0
 Dw_m1                0.0      0.0

 Ir_mm                0.0      0.0
 Dr_mm                0.0      0.0
 Dw_mm                0.0      0.0

utf8.c: Add indentation

This is in preparation for the next commit, so the diff command is less
confused

Don't try to case change surrogates, above-Unicodes

Changing the case (upper, lower, title, fold) of surrogate code points
and non-Unicode code points always yields the original, so there is no
need to actually try it.  And trying it is slow and creates swashes,
which uses up runtime memory.  We test for these code points anyway, so
at the cost of just two gotos and a label, we can skip all that work and
potential memory use.  This is worth doing even though such usage will
be rare in practice.

Running the following command

    blead Porting/bench.pl --perlargs="-Ilib -X" --benchfile=above_unicode path_to_prior_perl=before_this_commit path_to_this_perl=after

on a -O2 no DEBUGGING perl, where file 'above_unicode" contains

    [
        'string::casing::above_unicode' => {
            desc    => 'yes cases vs no casing',
            setup   => 'my $a = "\x{110000}"',
            code    => 'my $b = uc($a)'
        },
    ];

yields this output (the extra cost of swash creation is not included):

 The numbers represent raw counts per loop iteration.

 string::casing::above_unicode
 yes cases vs no casing

        before_this_commit    after
        ------------------ --------
     Ir             1329.0    651.0
     Dr              324.0    190.0
     Dw              149.0     94.0
   COND              192.0    103.0
    IND               13.0     10.0

 COND_m                5.5      0.0
  IND_m                6.0      4.0

  Ir_m1                0.1      0.0
  Dr_m1                0.0      0.0
  Dw_m1                0.0      0.0

  Ir_mm                0.0      0.0
  Dr_mm                0.0      0.0
  Dw_mm                0.0      0.0

Fix awkward wording in 'say' documentation

For: RT #126833

reword $@ documentation (it's not just for syntax errors)

RT #124034

utf8.c: Don't throw away a value and then recalc it

In half the calls to to_utf8_case(), the code point being looked up is
known.  It is thrown away because the API doesn't pass it, and then
recalculated first thing in to_utf8_case.

Fix this by making a new static function which adds the code point to
the parameter list, and change all calls to use this, leaving the
existing to_utf8_case() as just a wrapper for the new function.

embed.fnc: White-space only

perlapi: Vaguely deprecate to_utf8_case

by giving alternatives to use instead.

utf8.c: Add some LIKELY(), UNLIKELY()

perlgit.pod: update 'git status' sample output

perlgit.pod: standardize on % as shell prompt

utf8.h, utfebcdic.h: Add #define

for future use

utf8.h: Fix macro definition

This has been wrong, and won't compile, should anyone have tried, since
635e76f560b3b3ca075aa2cb5d6d661601968e04 earlier in 5.23.

utf8.h: Remove unused #define

UTF8_QUAD_MAX is no longer used in the core, and is not in cpan, and its
name is highly misleading.  It is defined to be 2**36, which has really
nothing to do with what its name indicates.

t/lib/warnings/utf8: Add some tests

These better test the detection of surrogates, noncharacters, and
above-Unicode code points.

Achim Gratz is now a perl author

[perl #126834] Cygwin cygdrive prefix test

* t/lib/cygwin.t: Use the /proc virtual filesystem to determine the
  cygdrive prefix.  If that isn't available, fall back to using the
  cygpath executable instead of parsing the output from df or mount
  for older Cygwin.  That fallback can fail if C:\ is manually mounted
  someplace else, but the former code had the same problem.

[MERGE] rpeep() consistent oldoldop -> oldop -> o

rpeep() assert oldoldop -> oldop -> o form a chain

In rpeep(), in a loop, the var o becomes each op in the op_next chain in
turn. At the same time, oldop is set to the previous value of o, and
oldoldop the previous but one.

Some places that modify the op_next chain weren't correctly upodating
oldop and oldoldop at the same time. Last few commits have fixed those
places.

This commit adds an assert at the top of loop to check that oldoldop and
oldop are in fact consistent.

(This assert was used to find the faults fixed in the previous couple of
commits).

rpeep: maintain chain when handling for(reverse..)

There's code in rpeep() that eliminates the reverse op from
for (reverse ....) {} and just flags the enteriter as needing to reverse
its args.

This code didn't leave oldoldop -> oldop -> o as a consistent chain of
adjacent op_next ops.

rpeep: maintain chain when del extra nextstates

There's code in rpeep() that eliminates duplicate nextstate ops.
E.g.

    FOO -> NEXTSTATE1 -> NULL -> ... -> NULL -> NEXTSTATE2 -> ...

becomes

    FOO --------------------------------------> NEXTSTATE2 -> ...

This code didn't leave oldoldop -> oldop -> o as a consistent chain of
adjacent op_next ops.

stop the eliding of void $pkg_var from assert fail

The code to eliminate things like our($foo); from the runtime op_next
chain in rpeep() caused the oldoldop, oldop, o vars not to form a chain of
3 adjacent ops. Instead, oldoldop and oldop ended up equal, which later
caused an assertion failure in the padrange code for something like

    my($a,$b),$x,my($c,$d);

utf8.c: Fix broken EBCDIC compilation

Commit ba6ed43c6aca7f1ff5a1b82062faa3e1c33c0582 left out a '}' which is
skipped except in EBCDIC builds.  (I meant to make sure things would
compile (by reversing the sense of the #if's) on EBCDIC, but forgot at
the time it should have been done.)