Don’t stringify undef hash keys at compile time

$ ./perl -wIlib -Mconstant' u=>undef' -e '()=$a{+u} if $a'
Use of uninitialized value at -e line 1.

Well, I didn’t even execute that hash lookup, so why is it warning me
about an uninitialized value?

This is a compile-time optimisation to turn hash keys into shared hash
key scalars (containing precomputed hashes) to speed up key lookup.
It stringifies the hash key at compile time as part of the process.

The value should not be stringified if that would cause observable
difference with tied hashes.  Commit 04698ff67 fixed this for refs,
globs and regexps, but missed undef scalars.

This could be considered part of bug #79178.
Respect SvLEN==0 and SvOOK in sv.c:sv_sethek

SvLEN==0 means this scalar does not own the buffer, so it should
not free it.

SvOOK means that SvPVX does not point to the start of the buffer
because we have cheated with s/...// or substr and not copied the
string back.

I don’t believe any such scalars currently make their way into
sv_sethek and get past the THINKFIRST check in that state, but we
should still play it safe.

SvPV_free handles both cases.
Avoid assert fail with s// $target = \3 /e

When the substitution target is assigned to in pp_substcont, it is
assumed that SvPV_free and SvPOK_only_UTF8 can be used on that target.
Only COW scalars are sent through sv_force_normal.

Changing the target in the replacement code can render those assump-
tions untrue:

$  ./perl -Ilib -e '$h = 3; $h =~ s/3/$h=\3;4/e'
Assertion failed: (!((targ)->sv_flags & 0x00000800) || !(*({ SV *const _svrv = ((SV *)({ void *_p = (targ); _p; })); (__builtin_expect(!(PL_valid_types_RV[((svtype)((_svrv)->sv_flags & 0xff)) & 0xf]), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "PL_valid_types_RV[SvTYPE(_svrv) & SVt_MASK]") : (void)0); (__builtin_expect(!(!((((_svrv)->sv_flags & (0x00004000|0x00008000)) == 0x00008000) && (((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVGV || ((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVLV))), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "!isGV_with_GP(_svrv)") : (void)0); (__builtin_expect(!(!(((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVIO && !(((XPVIO*) (_svrv)->sv_any)->xio_flags & 64))), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "!(SvTYPE(_svrv) == SVt_PVIO && !(IoFLAGS(_svrv) & IOf_FAKE_DIRP))") : (void)0); &((_svrv)->sv_u.svu_rv); }))), function Perl_pp_substcont, file pp_ctl.c, line 269.
Abort trap: 6

Also, matching against a hash key and locking that key with Hash::Util
within the replacement code can cause the substitution to modify that
hash key without triggering ‘Modification of a read-only value’.  But
this only happens if it is not a copy-on-write scalar:

$ ./perl -Ilib -MHash::Util=lock_hash -le '$h{foo} = 3; $h{foo} =~ s/3/$h{foo} = 3; lock_hash %h; 4/e; print $h{foo}'
4

We need to do a regular SV_THINKFIRST_COW_DROP check here, just as we
do in sv_setsv with regular scalar assignment.

Also, we need to take into account real globs:

$ ./perl -Ilib -MHash::Util=lock_hash -le '$::{foo} =~ s//*{"foo"}; 4/e'
Assertion failed: (!isGV_with_GP(targ)), function Perl_pp_substcont, file pp_ctl.c, line 259.
Abort trap: 6
op.c:ck_eval: remove redundant null check

op_first is never null when OPf_KIDS is set.
dump.c: Dump contents of regexps’ mother_re field

This can make debugging easier if one needs to see the reference count
of the parent regular expression.
Revert "toke.c:incline: Avoid duplicate symbol lookup"

This reverts commit 05c9917c892c03577828027ff71c6282a2eabe29.

This is in preparation for reverting c82ecf346, which will remove the
CopFILEGV_set macro under threads.
Revert "[perl #117855] Store CopFILEGV in a pad under ithreads"

This reverts commit c82ecf346.

It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread.  So when you free the cop, how do you know where to do
SvREFCNT_dec?

In reverting c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
toke.c:S_incline: avoid vivifying GV under threads

Since c82ecf346 has been reverted by the previous commit, under
threads we are back to storing the name of the current file in the
cop, rather than a pointer to the GV.  This means the GV may not even
have been created, so CopFILEGV will autovivify it.  We can avoid
autovivifying it in those cases where we are not going to be copying
the lines anyway, which S_incline only does for string eval (when it
sees a #line directive).  Even if the GV already exists, this makes
the check faster, as we no longer have to look it up by name when
parsing a file.
Make constant folding use the right hints

This was brought up in ticket #117855.

PL_compiling is a cop-sized static buffer (inside the interpreter
struct under threads) that stores information during compile time
(such as file name and line number) that gets copied to each cop (con-
trol op; aka state op or nextstate op) as it is created.

Some values are not actually stored in PL_compiling, such as the
current stash (PL_curstash is used instead) and the current hints
(PL_hints is used).

The ops in each statement are created before that statement’s cop
is created.

At run time, each cop is executed at the start of the statement and
sets PL_curcop to point to itself, so that operators within that
statement can get information from PL_curcop.

Constant folding was copying the contents of PL_compiling into a tem-
porary cop used to execute the ops being folded.  That constant fold-
ing happened of course before the cop was created for that statement.

Now it just happened that commit a0ed51b321 back in 1998 modified
newSTATEOP to copy hints to PL_compiling in addition to the new cop
being created.  Presumably that was to fix the type of bug that this
commit is addressing.  (Presumably this commit renders those changes
unnecessary.)  That meant that most of the time constant folding would
see the right hints.

That fails, though, when it comes to the first statement in a string
eval.  When you do eval("uc(ä)"), the constant folding happens when
PL_compiling.cop_hints still points to whatever value it had before
the eval was executed; i.e., an unpredictable value.  Slight changes
to unrelated scopes (and, apparently, using a different compiler*) can
cause the result of that string eval to change.

The solution is to set the hints from PL_hints explicitly when doing
constant folding.

* <https://rt.perl.org/rt3/Ticket/Display.html?id=117855#txn-1241613>ff.
  I never got to the bottom of why the compiler would make a diffe-
  rence here.  Finding out would involve setting a watchpoint on
  PL_compiling.cop_hints in a C debugger and then stepping through
  the thousands of times PL_compiling changes, which is too much
  work.  Nevertheless, I know this fix is correct, as it changes
  PL_compiling.cop_hints from having a non-deterministic value during
  constant folding to having a predictable one.