Add inlinable &CORE::functions

This commit allows this to work:

  BEGIN { *entangle = \&CORE::tie };
  entangle $foo, $package;

And the entangle call gets inlined as a tie op, the resulting op tree
being indistinguishable.

These subs are not yet callable via &foo syntax or through a refer-
ence.  That will come later, except for some functions, like sort(),
which will probably never support it.

Almost all overridable functions are supported.  These few are not:

  - infix operators
  - not and getprotobynumber (can’t get the precedence right yet;
    prototype problem)
  - dump

Subsequent commits (hopefully!) will deal with those.

How this works:

gv_fetchpvn_flags is extended with hooks to create subs inside the
CORE package.  Those subs are XSUBs (whose C function dies with an
error, for now at least) with a call checker that blows away the
entersub op and replaces it with whatever op the sub represents.

This is slightly inefficient right now, as gv_fetchpvn_flags calls
keyword(), only to have core_prototype call it again.  That will
be fixed in a future refactoring.

1 files changed, 4 insertions, 2 deletions

diff --git a/pod/perlsub.pod b/pod/perlsub.pod
index 4cc0b9c5e7..d344c4745c 100644
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -1309,8 +1309,10 @@ built-in name with the special package qualifier C<CORE::>.  For example,
 saying C<CORE::open()> always refers to the built-in C<open()>, even
 if the current package has imported some other subroutine called
 C<&open()> from elsewhere.  Even though it looks like a regular
-function call, it isn't: you can't take a reference to it, such as
-the incorrect C<\&CORE::open> might appear to produce.
+function call, it isn't: the CORE:: prefix in that case is part of Perl's
+syntax, and works for any keyword, regardless of what is in the CORE
+package.  Taking a reference to it, that is, C<\&CORE::open>, only works
+for some keywords.  See L<CORE>.
 
 Library modules should not in general export built-in names like C<open>
 or C<chdir> as part of their default C<@EXPORT> list, because these may