toke.c: Quit now if error at end of input

In these two cases, we know we are at the end of the input, and that we
have an error.  There is no need to try to patch things up so we can
continue to parse looking for other errors; there's nothing left to
parse.  So skip having to deal with patching up.

toke.c: Un-special case something

By refactoring slightly, we make this code in a switch statement
have the same entrance and exit invariants as the other cases, so they
all can be handled uniformly at the end of the switch.

Don't try to compile a pattern known to be in error

Regular expression patterns are parsed by the lexer/toker, and then
compiled by the regex compiler.  It is foolish to try to compile one
that the parser has rejected as syntactically bad; assumptions may be
violated and segfaults ensue.  This commit abandons all parsing
immediately if a pattern had errors in it.  A better solution would be
to flag this pattern as not to be compiled, and continue parsing other
things so as to find the most errors in a single attempt, but I don't
think it's worth the extra effort.

Making this change caused some misleading error messages in the test
suite to be replaced by better ones.

toke.c: Add internal function to abort parsing

This is to be called to abort the parsing early, before the required
number of errors have been found.  It is used when continuing the parse
would be either fruitless or we could be looking at garbage.

toke.c: White-space only

Indent after the previous commit enclosed this code in a new block.

Relax internal function API

This changes  yyerror_pvn so that its first parameter can be NULL.  This
indicates no message is to be output, but that parsing is to be
abandoned immediately, without waiting for more errors to build up.

Extract code into a function

This creates a function in toke.c to output the compilation aborted
message, changing perl.c to call that function.  This is in preparation
for this to be called from a 2nd place

toke.c: Rmv no longer necessary UTF-8 checks

The previous commit tightened up the checking for well-formed UTF8ness,
so that the ones removed here were redundant.

The test during a string eval may also no longer be necessary, but since
there are many ways to create that string, I'm not confidant enough to
remove it.

Add test for [perl #130675]

t/lib/croak/toke_l1: Cut down test

The previous commits hardening toke.c against malformed UTF-8 input have
allowed this test case to be cut down substantially

toke.c: Fix bugs where UTF-8 is turned on in mid chunk

Previous commits have tightened up the checking of UTF-8 for
well-formedness in the input program or string eval.  This is done in
lex_next_chunk and lex_start.  But it doesn't handle the case of

    use utf8; foo

because 'foo' is checked while UTF-8 is still off.  This solves that
problem by noticing when utf8 is turned on, and then rechecking at the
next opportunity.

See thread beginning at
http://nntp.perl.org/group/perl.perl5.porters/242916

This fixes [perl #130675].  A test will be added in a future commit

This catches some errors earlier than they used to be and aborts. so
some tests in the suite had to be split into multiple parts.

mg.c: PL_hints is unsigned

Therefore it's dangerous to presume things fit into an IV.

toke.c: Add branch prediction

The input is far more likely to be well-formed than not.

toke.c: Fix comments describing S_tokeq

The comments about what this function does were incorrect.

toke.c: Slight refactor.

This moves an automatic variable to closer to the only place it is used;
it also adds branch prediction.  It is likely that the input will be
well-formed.

toke.c: White space, comments, braces

I am adding the braces because in one of the areas, the lack of braces
had led to a blead failure.

toke.c: Don't compare same bytes twice

Before starting this memEQ, we know that the first bytes are the same,
so might as well start the compare with the 2nd bytes.

toke.c: Move declaration

This automatic variable doesn't need such a large scope.

perly.c: Clarify comment

sv.h: Add comment

Merge branch 'sawyerx/undeprecate-backslash-c' into blead

Revert "Deprecating the use of C<< \cI<X> >> to specify a printable character."

This reverts commit bfdc8cd3d5a81ab176f7d530d2e692897463c97d.

Revert "Avoid triggering a deprecation warnings."

This reverts commit 5ad2a0b67cdf1d90b67b991ae8708d3b9d57bad9.

We have decided to undeprecate \c. Please see:
http://www.nntp.perl.org/group/perl.perl5.porters/2017/01/msg242693.html

pp_pack.c: Remove no longer relevant comment

pp_pack.c: Remove needless branch

This function only sets *retlen to 0 if the input length is 0.  In all
but one case, the function was not called with with that input.  In that
one case, I changed to avoid calling the function with that input.
Hence we can remove checking *retlen for 0.

pp_pack.c: Remove obsolete code

This code effectively reduced to

 if (foo) 0 else 0

because a #define was changed to 0 some releases ago.  Just replace by

 0

utf8.c: Move comment a few lines up in the file

Move it to where it makes more sense.

utf8.h: Clarify comment

utf8.h: White-space, parens only

Add parens to clarify grouping, white-space for legibility

utf8.h: Add branch prediction

use bytes;

is unlikely to be the case.

(perl #126203) build issues

helps to test builds with the right options...

Change av_foo_nomg() name

These names sparked some controversy when created:

http://www.nntp.perl.org/group/perl.perl5.porters/2016/03/msg235216.html

I looked through existing code for paradigms to follow, and found some
occurrences of 'skip_foo_mg'.  So this commit changes the names to be

    av_top_index_skip_len_mg()
    av_tindex_skip_len_mg()

This is explicit about the type of magic that is ignored, and will still
be valid if another type of magic ever gets added.

Coverity #28930: unchecked return value

Strangely, this was apparently found already in 2014, but it now
(rightfully) showed up.  Coverity database tweak?

Net::Ping: Todo a test on EBCDIC

This is just to get it to pass.  It appears to be a permissions problem
on our one smoker.

Coverity #155950: pRExC->code_blocks is blindly derefed

Even though code calling S_pat_upgrade_to_utf8 from the
Perl_re_op_compile is testing the code_blocks for NULLness.

regcomp.c: Fix so will compile on C++11

See 147e38468b8279e26a0ca11e4efd8492016f2702 for complete explanation

(perl #126203) avoid potential leaks on quadmath_snprintf() failure

In the unlikely case quadmath_snprintf() fails both sv_vcatpvfn_flags()
and my_snprintf() could leak the temp format string returned by
quadmath_format_single() if quadmath_format_single() had to rebuild
the format.

Getting quadmath_snprintf() to fail in this context seems impractical,
but future changes may make it happen, so clean up after ourselves.

Getopt::Std: Changed pod NAME to follow convention

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

locale.c: Use only C89 legal C

An array was being declared and initialized from a non-constant.

Spotted by James Keenan

Add TODO test for [perl #125493]

perldelta for d6851fe9ee8e

(perl #130705) don't convert match with argument to qr

Code like:

  0 =~ qr/1/ ~~ 0

would have the match operator replaced with qr, leaving an op tree
like:

e  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v:{ ->3
d     <@> print vK ->e
3        <0> pushmark s ->4
c        <2> aelem sK/2 ->d
5           <1> rv2av[t1] sKR/1 ->6
4              <$> gv(*0) s ->5
b           <2> smartmatch sK/2 ->c
9              </> qr() sKS ->a  <=== umm
6                 <$> const(IV 0) s ->7
8                 <|> regcomp(other->9) sK ->9
7                    </> qr(/"1"/) s ->8
a              <$> const(IV 0) s ->b

when executed, this would leave an extra value on the stack:

$ ./perl -Dst -e 'print(0->[0 =~ qr/1/ ~~ 0])'
Smartmatch is experimental at -e line 1.

EXECUTING...

    =>
(-e:0)  enter
    =>
(-e:0)  nextstate
    =>
(-e:1)  pushmark
    =>  *
(-e:1)  gv(main::0)
    =>  *  GV()
(-e:1)  rv2av
    =>  *  AV()
(-e:1)  const(IV(0))
    =>  *  AV()  IV(0)
(-e:1)  qr
    =>  *  AV()  IV(0)  \REGEXP()
(-e:1)  regcomp
    =>  *  AV()  IV(0)
(-e:1)  qr
    =>  *  AV()  IV(0)  \REGEXP()
(-e:1)  const(IV(0))
    =>  *  AV()  IV(0)  \REGEXP()  IV(0)
(-e:1)  smartmatch
    =>  *  AV()  IV(0)  SV_NO
(-e:1)  aelem
    =>  *  AV()  SV_UNDEF  <=== trying to print an AV
(-e:1)  print
perl: sv.c:2941: Perl_sv_2pv_flags: Assertion `((svtype)((sv)->sv_flags & 0xff)) != SVt_PVAV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVHV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVFM' failed.
Aborted

pod: Do not suggest to use insecure :utf8 PerlIO layer when reading files

Instead use strict :encoding(UTF-8) PerlIO layer for input files.

Add test for [perl #129157]

perldelta for dd314e1ca8c3

(perl #130722) don't call SvPVX() on a glob

S_doparseform() called SvPVX() on the format argument, which
produced an assertion failure when the format was supplied as a
glob.

Since S_doparseform() calls SvPV() initially and stores the result,
just use that result.

Add .t for malformed-UTF-8 toke.c testing

This adds a non-UTF-8 encoded file to make it easier to test malformed
UTF-8 strings.  The file is automatically skipped on EBCDIC platforms.

The file is initialized with a test for [perl #129037], which had
already been unknowingly fixed by commit
75219bacf5aacd315b96083de24e82cd8238e99a

multideref: handle both OPpLVAL_INTRO,OPpDEREF

RT #130727

In a nested dereference like $a[0]{b}[1], all but the last aelem/helem
will normally have a OPpDEREF_AV/HV flag, while the last won't have a deref
but may well have OPpLVAL_INTRO, e.g.

    local $a[0]{b}[1] = 1;

The code in S_maybe_multideref() which converts a chain of aelem/helem's
into a single mltideref op assumes this - in particular that an op can't
have both OPpLVAL_INTRO and OPpDEREF* at the same time.  However, the
following code violates that assumption:

    @{ local $a[0]{b}[1] } = 1;

In @{expr} = 1, the array is in lvalue context, which makes expr be done
in ref (autovivify) context. So the final aelem in the above expression
gets both OPpLVAL_INTRO and OPpDEREF_AV flags.

In the old days, pp_aelem (probably more by luck than design) would action
OPpLVAL_INTRO and ignore OPpDEREF_AV. This commit makes pp_multideref
behave in the same way. In particular, there's no point in autovivifying
$a[0]{b}[1] as an array ref since the local() will be undone before it
gets a change to be used.

The easiest way to achieve this is to tun off the OPpDEREF flag on the
aelem/helem op if the OPpLVAL_INTRO flag is set.

perluniintro: Use uppercase UTF-8 encoding name

Reason is consistency with other documentation files.

perluniintro: Fix comment, Encode::decode does not have to return string with UTF8 flag set

perluniintro: Suggest to use utf8::decode() instead heavy Encode when sequence of bytes is valid UTF-8

pod: Suggest to use strict :encoding(UTF-8) PerlIO layer over not strict :encoding(utf8)

For data exchange it is better to use strict UTF-8 encoding and not perl's utf8.

[perl #129061] CURLYX nodes can be studied more than once

study_chunk() for CURLYX is used to set flags on the linked WHILEM
node to say it is the whilem_c'th of whilem_seen. However it assumes
each CURLYX can be studied only once, which is not the case - there
are various cases such as GOSUB which call study_chunk() recursively
on already-visited parts of the program.

Storing the wrong index can cause the super-linear cache handling in
regmatch() to read/write the byte after the end of poscache.

Also reported in [perl #129281].

(perl #129281) test for buffer overflow issue

vi hints for pat.t

Remove extra terminating semicolon

Detected by compiling with clang under -Weverything, which includes -Wextra-semi.

Reviewed by jhedden++.

Increment $VERSION in threads.pm.

Perl_fbm_instr(): remove dead code.

For the case where littlestr hasn't been FBM compiled (!SvVALID()), it
can't be SvTAIL(), so there's no need for optional \n handling.

Spotted by Coverity.

prevent leak of class name from retrieve_hook() on an exception

If supplied with a large class name, retrieve_hook() allocates
buffer for the class name and Safefree()s it on exit path.

Unfortunately this memory leaks if load_module() (or a couple of other
code paths) throw an exception.

So use SAVEFREEPV() to release the memory instead.

==20183== 193 bytes in 1 blocks are definitely lost in loss record 4 of 6
==20183==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20183==    by 0x55F85D: Perl_safesysmalloc (util.c:153)
==20183==    by 0x6ACA046: retrieve_hook (Storable.xs:4265)
==20183==    by 0x6AD6D19: retrieve (Storable.xs:6217)
==20183==    by 0x6AD8144: do_retrieve (Storable.xs:6401)
==20183==    by 0x6AD85B7: pretrieve (Storable.xs:6506)
==20183==    by 0x6AD8E14: XS_Storable_pretrieve (Storable.xs:6718)
==20183==    by 0x5C176D: Perl_pp_entersub (pp_hot.c:4227)
==20183==    by 0x55E1C6: Perl_runops_debug (dump.c:2450)
==20183==    by 0x461B79: S_run_body (perl.c:2528)
==20183==    by 0x46115C: perl_run (perl.c:2451)
==20183==    by 0x41F1CD: main (perlmain.c:123)

Fix stack buffer overflow in deserialization of hooks.

The use of signed lengths resulted in a stack overflow in retrieve_hook()
when a negative length was provided in the storable data.

The retrieve_blessed() codepath had a similar problem with the placement
of the trailing null byte when negative lengths were provided.

pp_formline: simplify growing of PL_formtarget

There's some reasonably complex logic to try and second guess how much
space to allocate or reallocate for the output buffer (some of which is
my doing from 2011, 26e935cfa6e7).

This commit removes most of this and now just does:

initially, grow the buffer by the size of the format. If any further
growing is needed later on (e.g. after a utf8 upgrade or due to @*) then
just grow as needed. This may give less optimal growing in edge cases
( i.e. repeated smaller grows rather than one big grow), but the old code
was often guessing wrong anyway.

This commit also makes it *always* check whether PL_formtarget needs growing
when about to append data to it, which is safer.

buffer overrun with format and 'use bytes'

RT #130703

In the scope of 'use bytes', appending a string to a format where the
format is utf8 and the string is non-utf8 but contains lots of chars
with ords >= 128, the buffer could be overrun. This is due to all the
\x80-type chars going from being stored as 1 bytes to 2 bytes, without
growing PL_formtarget accordingly.

This commit contains a minimal fix; the next commit will more generally
tidy up the grow code in pp_formline.

Fix memory leak in generating an exception message

This was my fault; oops.

Fix outdated note in perldiag

As of 4fa06845e75d453a3101cff32e24c5b743f9819e, the "Odd name/value argument
for subroutine" error has been reported from the callers' perspective.

HvTOTALKEYS() takes a HV* as argument

Incidentally, it currently works on SV *'s as well because there's an
explicit cast after an SvANY. Let's not rely on that. This commit also
removes a pointless const in a cast. Again. It takes an HV * as argument.
Let's only change that if we have a strong reason to.

toke.c: Remove unused param from static function

Commit d2067945159644d284f8064efbd41024f9e8448a reverted commit
b5248d1e210c2a723adae8e9b7f5d17076647431.  b5248 removed a parameter
from S_scan_ident, and changed its interior to use PL_bufend instead of
that parameter.  The parameter had been used to limit how far into the
string being parsed scan_ident could look.  In all calls to scan_ident
but one, the parameter was already PL_bufend.  In the one call where it
wasn't, b5248 compensated by temporarily changing PL_bufend around the
call, running afoul, eventually, of the expectation that PL_bufend
points to a NUL.

I would have expected the reversion to add back both the parameter and
the uses of it, but apparently the function interior has changed enough
since the original commit, that it didn't even think there were
conflicts.  As a result the parameter got added back, but not the uses
of it.

I tried both approaches to fix this:
    1) to change the function to use the parameter;
    2) to simply delete the parameter.
Only the latter passed the test suite without error.

I then tried to understand why the parameter in the first place, and why
the kludge introduced by b5248 to work around removing it.  It appears
to me that this is for the benefit of the intuit_more function to enable
it to discern $] from a $ ending a bracketed character class, by ending
the scan before the ']' when in a pattern.

The trouble is that modern scan_ident versions do not view themselves as
constrained by PL_bufend.  If that is reached at a point where white
space is allowed, it will try appending the next input line and
continuing, thus changing PL_bufend.  Thus the kludge in b5248 wouldn't
necessarily do the expected limiting anyway.  The reason the approach
"1)" I tried didn't work was that the function continued to use the
original value, even after it had read in new things, instead of
accounting for those.

Hence approach "2)" is used.  I'm a little nervous about this, as it may
lead to intuit_more() (which uses heuristics) having more cases where it
makes the wrong choice about $] vs [...$].  But I don't see a way around
this, and the pre-existing code could fail anyway.

Spotted by Dave Mitchell.

t/lib/warnings/toke: Fix comment typos

avoid double-freeing regex code blocks

RT #130650 heap-use-after-free in S_free_codeblocks

When compiling qr/(?{...})/, a reg_code_blocks structure is allocated
and various SVs are attached to it. Initially this is set to be freed
via a destructor on the savestack, in case of early dying. Later the
structure is attached to the compiling regex, and a boolean flag in the
structure, 'attached', is set to true to show that the destructor no
longer needs to free the struct.

However, it is possible to get three orders of destruction:

1) allocate, push destructor, die early
2) allocate, push destructor, attach to regex, die
2) allocate, push destructor, attach to regex, succeed

In 2, the regex is freed (via the savestack) before the destructor is
called. In 3, the destructor is called, then later the regex is freed.

It turns out perl can't currently handle case 2:

    qr'(?{})\6'

Fix this by turning the 'attached' boolean field into an integer refcount,
then keep a count of whether the struct is referenced from the savestack
and/or the regex. Since it normally has a value of 1 or 2, it's similar
to a boolean flag, but crucially it no longer just indicates that the
regex has a pointer to it ('attached'), but that at least one of the
savestack and regex have a pointer to it. So order of freeing no longer
matters.

I also updated S_free_codeblocks() so that it nulls out SV pointers in
the reg_code_blocks struct before freeing them. This is is generally good
practice to avoid double frees, although is probably not needed at the
moment.

(perl #130684) allocate enough space for the extra 'x'

77c8f26370dcc0e added support for a doubled x regexp flags, and ensured
the doubled flag was passed to the qr// created by
S_compile_runtime_code().

Unfortunately it didn't ensure enough space was allocated for that
extra 'x'.

PATCH: [perl #130655] Unrecognized UTF-8 char

The root cause of this was code like this

    if (a)
        b

which got changed into

    if (a)
        c
        b

thus causing 'b' to being changed to be executed unconditionally.  The
solution is just to add braces

    if (a) {
        c
        b
    }

This is why I always use braces even if not required at the moment.  It
was the coding standard at $work.

It turns out that #130567 doesn't even come up with this fix in place.

PATCH: [perl #130656] tr// failue with UTF-8 across lines

This bug happend under things like

tr/\x{101}-\x{200}/
   \x{201}-\x{301}/

The newline in the middle was crucial.  As a result the second line got
parsed already knowing that the result was UTF-8, and as a result
setting a variable got skipped which happens only when we discover we
need to flip into UTF-8.

The solution adopted here is to set the variable under other conditions,
which leads to it getting set multiple times.  But this extra branch and
setting is confined to somehwat rare circumstances, leaving the mainline
code untouched.

signature sub (\x80 triggered an assertion

RT #130661

In the presence of 'use feature "signatures"', a char >= 0x80 where a sigil
was expected triggered an assert failure, because the (signed) character
was being was being promoted to int and ended up getting returned from
yylex() as a negative value.

Add test for [perl #129036]

This was fixed by 6cdc5cd8f36f88172b0fcefdcadec75f5b6600b2
(but I didn't check that this was the actual commit).

PATCH: [perl #130666]: Revert "toke.c, S_scan_ident(): Don't take a "end of buffer" argument, use PL_bufend"

This reverts commit b5248d1e210c2a723adae8e9b7f5d17076647431.

This commit, dating from 2013, was made unnecessary by later removal of
the MAD code.  It temporarily changed the PL_bufend variable; doing that
ran afoul of an assertion, added in
fac0f7a38edc4e50a7250b738699165079b852d8, that expects PL_bufend to
point to a terminating NUL.

Beyond the reversion, a test is added here.

mention PASS2 in reginsert() example

As per bb78386f13.

assert that the RExC_recurse data structure points at a valid GOSUB

This assert will fail if someone adds code that optimises away a GOSUB
call. At which point they will see the comment and know what to do.

silence warnings from tests about impossible quantifiers

thanks to Dave M for noticing....

in dump_sub() handle CV ref used as GV

dump_sub() can receive a CV ref where it's expecting a GV.  Make it
handle that cleanly.  Fixes [perl #129126].

croak on sv_setpvn() on a glob

A real glob cannot be written to as a string scalar, and a sv_setpvn()
call attempting to do so used to hit an assertion.  (sv_force_normal()
coerces glob copies to strings, but leaves real globs unchanged.)
This isn't exposed through assignment ops, which have special semantics
for assignments to globs, but it can be reached through XS subs that
mutate arguments, and through "^" formats.  Change sv_setpvn() to check
for globs and croak cleanly.  Fixes [perl #129147].

only mess with NEXT_OFF() when we are in PASS2

In 31fc93954d1f379c7a49889d91436ce99818e1f6 I added code that would modify
NEXT_OFF() when we were not in PASS2, when we should not do so. Strangly this
did not segfault when I tested, but this fix is required.

Reuse previously-computed flag

add some details to the docs for S_reginsert()

Had these docs been here I would have saved some time debugging. So
save the next guy from the same trouble... (with my memory *I* might
even be the /next guy/. Sigh.)

fix RT #130561 - recursion and optimising away impossible quantifiers are not friends

Instead of optimising away impossible quantifiers like (foo){1,0} treat them
as unquantified, and guard them with an OPFAIL. Thus /(foo){1,0}/ is treated
the same as /(*FAIL)(foo)/ this is important in patterns like /(foo){1,0}|(?1)/
where the (?1) needs to be able to recurse into the (foo) even though the
(foo){1,0} can never match. It also resolves various issues (SEGVs) with patterns
like /((?1)){1,0}/.

This patch would have been easier if S_reginsert() documented that it is
the callers responsibility to properly set up the NEXT_OFF() of the inserted
node (if the node has a NEXT_OFF())

rename opnd to operand to save my sanity

Fix wrong skippage when using -DPERL_DEBUGGING_MSTATS but not -DDEBUGGING

fix ord of upgraded empty string

pp_ord fell foul of the new API stricture added by
d1f8d421df731c77beff3db92d27dc6ec28589f2.  Change it to avoid calling
utf8n_to_uvchr() on an empty string.  Fixes [perl #130545].

fix range op under aborted constant folding

When constant-folding a range/flipflop construct, the op_next threading
of peephole optimisation caused multiple ops in the construct to have
a null op_next, because the final (and top-level) op in the construct
is a null op.  This meant that simple restoration of the top-level
op's op_next after execution wouldn't get it back into a fit state
to be composed with other ops.  In the event that the range construct
couldn't be constant-folded this made it compile to a broken optree.
If it couldn't be constant-folded but could actually be executed, for
example because it generated a warning, this meant the brokenness would
be encountered at runtime.  Execution would stop after the range op,
because of the null op_next.

To avoid this, temporarily mark the null op as a custom op during the
peephole optimisation that supports the execution for constant-folding.
This prevents it being op_next-threaded out, so simple op_next restoring
then works.  If the constant-folding is aborted, it compiles to an
operational optree.  However, the suppression of duplicate peephole
optimisation means that the null op is never ultimately threaded out
as it should be.  For the time being, this stands as a cost of failed
constant-folding of range constructs.

Fixes [perl #130639].

Correct file mode and line lengths to keep porting tests happy.

document nature and use of $a and $b in sort()

Signed-off-by: Abigail <abigail@abigail.be>

Test for [perl #130567]

This was omitted from 90b58c702e376ab45f13a7f10e14d8c786d05d8a.

perlapi: Fix grammar

pod: Suggest to use strict UTF-8 encoding when dealing with external data

For data exchange it is not good idea to use not strict perl's extended
dialect of utf8 encoding.

perluniintro: Encode::encode_utf8() not always appropriate

Do not suggest to use Encode::encode_utf8() when you need to know the
byte length of a string Encode module could do some additional
operations and bytes pragma is supposed to do that job.

Add Pali to AUTHORS

Update McUpdate

Cherry-pick Scalar-List-Utils tainted.t fix from upstream

It's fixed properly upstream, by using $^X instead of %ENV, so use that
instead of the now-expired skip.

Regenerate customized.dat

As of commit 254707bab3 cpan/CPAN is in sync with upstream.

PATCH: [perl #130567] Assertion failure in scan_const

It turns out that eval text isn't necessarily parsed by
lex_next_chunk(), but is by lex_start().  So, add a test to there to
look for malformed UTF-8.

Fix embed.fnc for utf8_to_uvchr_buf

Documentation patch to recommend newSVpvn over newSVpv.

(Committer made a couple of grammatical corrections)

regexec.c: Clarify comment

This now explains why we allow the input pointer to go off by 1 at the
end.