Stop $^H |= 0x1c020000 from enabling all features

That set of bits sets the feature bundle to ‘custom’, which means that
the features are set by %^H, and also indicates that %^H has been did-
dled with, so it’s worth looking at.

In the specific case where %^H is untouched and there is no corres-
ponding cop hint hash behind the scenes, Perl_feature_is_enabled (in
toke.c) ends up returning TRUE.

Commit v5.15.6-55-g94250ae sped up feature checking by allowing
refcounted_he_fetch to return a boolean when checking for existence,
instead of converting the value to a scalar, whose contents we are not
even going to use.

This was when the bug started happening.  I did not update the code
path in refcounted_he_fetch that handles the absence of a hint hash.
So it was returning &PL_sv_placeholder instead of NULL; TRUE instead
of FALSE.

This did not cause problems for most code, but with the introduction
of the new bitwise ops in v5.21.8-150-g8823cb8, it started causing
uni::perl to fail, because they were implicitly enabled, making ^ a
numeric op, when it was being used as a string op.

1 files changed, 8 insertions, 0 deletions

diff --git a/t/lib/feature/bundle b/t/lib/feature/bundle
index a5a67846c9..b9facc0bd6 100644
--- a/t/lib/feature/bundle
+++ b/t/lib/feature/bundle
@@ -117,3 +117,11 @@ EXPECT
 Use of assignment to $[ is deprecated at - line 2.
 Assigning non-zero to $[ is no longer possible at - line 5.
 b
+########
+# NAME $^H accidentally enabling all features
+eval 'BEGIN { $^H |= 0x1c020000 } $_ = evalbytes 12345';
+print $_||$@;
+EXPECT
+Number found where operator expected at (eval 1) line 1, near "evalbytes 12345"
+	(Do you need to predeclare evalbytes?)
+syntax error at (eval 1) line 1, near "evalbytes 12345"