Add &CORE::pos
coreamp.t: rename badly-named tests
Add &CORE::prototype
Remove OPpCONST_WARNING

This was added to op.h in commit 599cee73:

commit 599cee73f2261c5e09cde7ceba3f9a896989e117
Author: Paul Marquess <paul.marquess@btinternet.com>
Date:   Wed Jul 29 10:28:45 1998 +0100

    lexical warnings; tweaks to places that didn't apply correctly
    	Message-Id: <9807290828.AA26286@claudius.bfsec.bt.co.uk>
    	Subject: lexical warnings patch for 5.005_50

    p4raw-id: //depot/perl@1773

dump.c was modified to dump in, in this commit:

commit bf91b999b25fa75a3ef7a327742929592a2e7e9c
Author: Simon Cozens <simon@netthink.co.uk>
Date:   Sun May 13 21:20:36 2001 +0100

    Op private flags
    Message-ID: <20010513202036.A21896@netthink.co.uk>

    p4raw-id: //depot/perl@10117

But is apparently completely unused anywhere.  And I want that bit.
Increase $B::Concise::VERSION to 0.90
Remove OPpCONST_WARNING from B::Concise
Record folded constants in the op tree
Allow require_errors.t to be run from the top level
require_errors.t: Test <> error
override.t: Remove obsolete comment
Make while(each ...) imply defined($_ = ...)

This came up in ticket #108286.

Quoting Nicholas Clark:
>
>     while (<STDIN>)
>     while (<*>)
>
> These both always implicitly assigned to $_, always implicitly
> added defined.
>
>     while ($_ = <STDIN>)
>     while ($a = <STDIN>)
>     while ($_ = <*>)
>     while ($a = <*>)
>     while ($_ = readdir D)
>     while ($a = readdir D)
>     while ($_ = each %h)
>     while ($a = each %h)
>
> The implicit defined added was by commit 4b161ae29769b4a3,
> //depot/maint-5.004/perl@949
>
>
> BUT:
>
>     while (readdir D)
>
> The implicit assignment to $_ and defined test were both added in
> *2009* (by commit 114c60ecb1f7)
>
>
> leaving:
>
>     while (each %h)
>
>
> So it is the odd one out. And in 2009 we felt comfortable to add
> both the implicit assignment and the defined test in blead for
> readdir, as a bug fix, and have had no reports of it caus-
> ing problems.

[He asked:]
> > > So that's a bug?

[And I responded:]
> > That's what I was trying to ask. :-)
>
> OK, after a quite a bit of deliberation and digging, I'm of the opinion that
>
> 1: yes, it's a bug

...

> So, there's only one use of while(each %...) on CPAN outside of
> debugging or test code, and that's only go the potential to break
> due to assignment now happening to to $_. Compared with 29 matches
> for while\s*\(\s*readdir of which 4 are .pm files. So
>
> 2: I think it's safe to fix it, just like readdir was fixed.

Just *as* readdir was fixed! :-)
Test that ‘require v5’ ignores sub named v5

This is something I broke in my first (unapplied) attempt to clean up
require’s parsing madness.
[perl #105926] Make ‘require 6’ a syntactic special case

This commit moves the special-casing for ‘require 6’ from pp_require
(run time) to op.c (optree-building time).  If the argument to require
is a constant (not counting folded constants) that is a number or a
vstring, the require op is flagged as being a version check, with the
newly-added OPpREQUIRE_VER flag.

This means that ‘require $ver’ no longer works, which could be consid-
ered an incompatible change (some tests had to change), but the bug
fix below makes it worth it.

Since CORE::require($_[0]) will no longer work from an override (actu-
ally a callback; see perl #108286), overrides are no longer called for
version checks like ‘require 5’.  The tests for this are marked to-do
for now, as they will be re-enabled (with ‘use feature "overrides"’)
when the ‘overrides’ feature comes into effect.

I left the lexing part of require as it was, since, although it is
clearly buggy, it is not clear exactly how things are supposed to
work.  See perl #107004.

This is the bug fix we get as a result:

These two lines:

    $x = "6"; require $x;
    $x = "6"; 0+$x; require $x;

should behave exactly the same way, but the latter was a version
check.  Now they are both file names.  And this no longer happens:

    $ perl5.12.4 -le '$x = "34 cabbages"; 0+$x; require $x'
    Invalid version format (non-numeric data) at -e line 1.

In this case, "34 cabbages" should obviously be a file name, but its
numeric representation was causing it to be treated as a version num-
ber; yet the version-parsing code used the string representation.
pp.c:pp_coreargs: use PL_op_desc instead of OP_DESC

Instead of using OP_DESC on op_next, since we already know the op
number, we can just go straight to PL_op_desc, which is what OP_DESC
itself uses after looking inside op_next to find out what the op
number is.

BTW, &CORE::scalar will need this, since a scalar op is never actu-
ally executed, making coreargs’ op_next pointer point to another op
than expected:

2  <1> leavesublv[1 ref] K/REFC,1 ->(end)
-     <1> scalar sKP/1 ->2
1        <$> coreargs(IV 2) s ->2
-e syntax OK

Otherwise we get ‘Not enough arguments for lvalue subroutine return’.
Add &CORE::scalar
Add &CORE::split
Add &CORE::study
Don’t crash with &CORE::foo after undefining *_

When a sub is called with & and no parentheses, no @_ is set up.  This
means the sub call sees the existing @_.  It also means that, if *_
has been undefined, there is no @_.

pp_coreargs was not accounting for this, and was doing
AvARRAY(GvAV(PL_defgv)) without checking that GvAV(PL_defgv) was non-
null.  It crashed as a result.
Add &CORE::undef

In the error message, we can’t say ‘&CORE::undef operator’, so we
should be using the op name, rather than the op description.

Instead of using OP_NAME(PL_op->op_next), which would expand to

    PL_op->op_next->op_type == OP_CUSTOM
	? XopENTRY(Perl_custom_op_xop(aTHX_ PL_op->op_next), xop_name)
	: PL_op_name[PL_op->op_next->op_type]

we can simply use PL_op_name[opnum], which should be quicker.

pp_undef can already handle nulls on the stack.

There is one remaining problem.  If &CORE::undef(\*_) is called, *_
will be undefined while @_ is localised during the sub call, so it
won’t have the same effect as undef *_.  I don’t know whether this
should be considered a bug or not, but I could solve it by making
pp_undef an XSUB.
op.c: Remove redundant assignment

This was added unnecessarily in commit ddeae0f14c.  It is a local
variable assigned to just before the function returns, so the value
is never used in the OP_UNDEF case.