Stop split from mangling constants

At compile time, if split occurs on the right-hand side of an assign-
ment to a list of scalars, if the limit argument is a constant con-
taining the number 0 then it is modified in place to hold one more
than the number of scalars.

This means ‘constants’ can change their values, if they happen to be
in the wrong place at the wrong time:

$ ./perl -Ilib -le 'use constant NULL => 0; ($a,$b,$c) = split //, $foo, NULL; print NULL'
4

I considered checking the reference count on the SV, but since XS code
could create its own const ops with weak references to the same cons-
tants elsewhere, the safest way to avoid modifying someone else’s SV
is to mark the split op in ck_split so we know the SV belongs to that
split op alone.

Also, to be on the safe side, turn off the read-only flag before modi-
fying the SV, instead of relying on the special case for compile time
in sv_force_normal.
index.t: Comment final brace

otherwise it can be quite confusing
Stop fbm_compile from flattening refs

References can change their stringification any time, so flattening
them ahead of time for efficiency gives incorect results.

Also, using a reference constant as the second argument to index
would result in the constant itself being flattened, even when used
elsewhere.
sv.h: Correct assertion in BmUSEFUL

BmUSEFUL uses the NV slot, not the IV slot.  So asserting that it is
not IOK is not all that useful.
Stop ck_index from flattening other people’s SVs

By passing to fbm_compile the SV that is the second argument to
index(), ck_index causes it to be stringified.

That means, for example, that dualvars will lose their numeric
representation and regexps will be flattened (affecting regexp
code blocks).

This patch allows POK-only SVs to be compiled into BMs in place, as
it just adds magic and does not otherwise affect them.  Other SVs get
copied first.

Also, I avoided a compile-time uninitialized warning by not running
fbm_compile on undef SVs.
util.c: Stop ck_index/fbm_compile from abusing readonliness

There is currently a convenient exception in sv_force_normal that
allows read-only scalars to be modified at compile time.

I want to get rid of it, since most code that relies on it is buggy.

So stop ck_index from relying on that when it calls fbm_compile by
stopping fbm_compile from triggering the error by forcing stringifica-
tion of variables that are already strings.
dump.c: Dump PV fields of SVt_PVIOs

Yes, these can hold PVs when source filters are involved.
Stop SVt_REGEXPs from being upgraded.

Any code that is going to write over a REGEXP will call
sv_force_normal first, which converts it to

This code started crashing in 5.12:

$_ = qr//;
@INC = sub { $_ };
require foo;

Search pattern not terminated at /loader/0x7fe3b082c2e8/foo.pm line 1.
Compilation failed in require at - line 4.
Segmentation fault: 11

With current bleadperl:

foo.pm did not return a true value at - line 4.
Segmentation fault: 11

This change makes it like this instead:

Can't upgrade REGEXP (8) to 15 at - line 3.

which is certainly an improvement.  We shouldn’t be getting any error
at all (OK, just a syntax error because (?^:) is not a valid expres-
sion), and the next commit will fix that, but this commit at least
turns a crash into a panic, in case future changes accidentally send a
regexp through sv_upgrade(sv, SVt_PVIO).
Copy scalar refs returned from @INC filters

This commit:

4464f08ea532be08ea7f0c44d0eb6e285a0c36fb is the first bad commit
commit 4464f08ea532be08ea7f0c44d0eb6e285a0c36fb
Author: Nicholas Clark <nick@ccl4.org>
Date:   Fri Oct 23 16:54:10 2009 +0100

    S_run_user_filter() can use the filter GV itself for the cache buffer.

    This saves allocating an extra SV head and body.

caused this:

$ perl -e '@INC = sub { \$_ }; eval { require foo }; $a = $_;'
Bizarre copy of IO in sassign at -e line 1.

Well, passing the existing string to filter_add causes that string
*itself* to be upgraded to SVt_PVIO, which is clearly not a good thing
if the caller can still reference it.  So we end up with $ bound to an
IO thingy.

And if the referent is a REGEXP, we get a crash during global destruc-
tion, or at least we did until the previous commit, which stopped
REGEXP->PVIO upgrades from being legal.  (Clearly they don’t work.)

The easiest way to fix this is to copy the string into a new scalar,
which then gets upgraded to PVIO.
toke.c: Don’t depend on sv_force_normal’s good graces

when parsing ‘keyword =>’ with comments or line breaks before the =>.

sv_force_normal will allow modification of read-only values at compile
time.  While this might be convenient, it has resulted in many bugs
elsewhere, so I am trying to change that.  This is a necessary pre-
requisite.
Increase $B::Deparse::VERSION to 1.22
sv.c: Make sv_force_normal always croak on ro SVs

Commit 8990e30710 (perl 5.0 alpha 6) changed several SvREADONLY checks
to apply only to run time.  This is convenient when it comes to modify-
ing op trees, whose SVs are, for the most part, marked read-only.

But several pieces of code that relied on this were buggy when dealing
with constants created by ‘use constant’.  To make it harder to add
such bugs, I have changed all code that relies on this exception and
am now removing it.
Remove ‘Can't coerce readonly %s’ error

$ ./perl -Ilib -e 'for(\1){ vec($_,0,1)=1 }'
Can't coerce readonly REF to string in sassign at -e line 1.

Why not ‘Modification of a read-only value’ as elsewhere?

The code in question, in sv_pvn_force_flags, allows references to
bypass the initial read-only check.  (This has been the case since
perl-5.005_02-1047-g6fc9266.  I think it was a mistake.)  Then there
is a check further down that croaks with this error, unless called as
SvPV_force_mutable (i.e., with the SV_MUTABLE_RETURN flag).

So that means read-only references can silently be flattened, regard-
less of the read-only flag, if the caller uses SvPV_force_mutable.
Fortunately, the only use of that macro in the core is in fbm_compile,
which I recently modified so that it wouldn’t touch references at all.

I don’t understand the logic that allows read-only thingies to be mod-
ified in the presence of the SV_MUTABLE_RETURN flag, but not other-
wise.  As of the previous commit, which removed the exception for
read-only scalars at compile time, nothing can reach that code except
read-only references.

This commit restores the logic inadvertently changed by 6fc9266 and
removes the code that becomes unreachable as a result.
[Merge] Fix bugs involving compilation and ro SVs

There was an exception in sv_force_normal_flags that allowed read-only
scalars to be modified at compile time (present since 8990e30710, aka
\perl 5.0 alpha 6), which is convenient for modifying op trees.

Unfortunately, much of the code relying on it was simply buggy.  So
this commit fixes those bugs and removes the exception.  In some cases
the bug fixes led to other bug fixes, not necessarily related to
sv_force_normal/SvREADONLY.