perldelta for ea238638ab

perldelta for 069abe75ae, ae2c6838c9 and fcea1f7ab3

perldelta for 7274b33cb1

perldelta for ca58dfd9e0

Update Module-Build to CPAN version 0.4200

  [DELTA]

0.4200 - Tue Nov 12 12:39:25 CET 2013

  - Released 0.40_11 as 0.4200

0.40_11 - Wed Nov  6 12:46:59 CET 2013

  [BUG FIXES]

  - Do not set provides in metadata if no_index is set [Leon Timmermans]

0.40_10 - Tue Nov  5 12:11:37 CET 2013

  [BUG FIXES]

  - Lowercase license in fallback logic [Leon Timmermans]

0.40_09 - Tue Nov  5 00:13:11 CET 2013

  [ENHANCEMENTS]

  - Converted to using Meta 2.0

perldelta for 71323522ef

perldelta for 0e706dd460 and e6307ed02e

perldelta for c41f466f88

perldelta: potential to-do item

I don’t understand this commit enough to know whether it warranst
inclusion, let alone to write a description for it.

perldelta for 8bfda0d7d5

perldelta for c7ea825dcc

perldelta for 8d9dd4b93f

perldelta for f789f6a4bd

perldelta for 8ee4c05d16

perldelta for 9f125c4af0

perldelta for e37958c391

perldelta for b2da7ead68

perldelta for 43e4250a61

perldelta for 4a2b275c6c

perldelta for 2be08ad105

perldelta for f03015cd13 and preceding commits

f03015cd13
475b1e904e
722fa0e997
4639d557ab
cf93a474d4
8465ba4524

perldelta for af230ad61a

perldelta for 8cece9139ae

perldelta for a854082c1d

perldelta for 5a2bc23bfe

perldelta: put things in the right sections

I could have sworn I had them in the right place.  I think git’s
ability to merge changes can be fooled.

perldelta for 2e73d70e52

perldelta for 2ec7f6f242 and a373464fd6

perldelta for 3c41103a26

perldelta for 2cf89ea7ef

perldelta for fea7fb25a

perldelta for 46879fadd0

perldelta for fcbc518d7a

In newATTRSUB, clear glob slot before lowering refcount.

(Actually in its subroutine, S_already_defined.)

Otherwise, when newATTRSUB redefines a sub, the previous sub’s DESTROY
can see the same sub still in the typeglob, but without a reference
count, so *typeglob = sub {} frees the sub currently in $_[0].

$ perl5.18.1 -le '
    sub foo{}
    bless \&foo;
    DESTROY {
        print "before: $_[0]"; *foo=sub{}; print "after: $_[0]"
    }
    eval "sub foo{}";
'
before: main=CODE(0x7fa88382d6d8)
before: main=CODE(0x7fa88382d6d8)
after: main=CODE(0x7fa88382d6d8)
after: UNKNOWN(0x7fa88382d6d8)

In newXS, clear glob slot before lowering refcount.

Otherwise, when newXS redefines a sub, the previous sub’s DESTROY can
see the same sub still in the typeglob, but without a reference count,
so *typeglob = sub {} frees the sub currently in $_[0].

$ perl5.18.1 -le '
    sub re::regmust{}
    bless \&re::regmust;
    DESTROY {
        print "before: $_[0]"; *re::regmust=sub{}; print "after: $_[0]"
    }
    require re;
'
before: main=CODE(0x7ff7eb02d6d8)
before: main=CODE(0x7ff7eb02d6d8)
after: main=CODE(0x7ff7eb02d6d8)
after: UNKNOWN(0x7ff7eb02d6d8)

Undeffing a gv in DESTROY triggered by undeffing the same gv

$ ./perl -Ilib -e 'sub foo{} bless \&foo; DESTROY { undef *foo } undef *foo'
Attempt to free unreferenced glob pointers, Perl interpreter: 0x7fd6a3803200 at -e line 1.

Lowering the reference count on the glob pointer only after freeing
the contents fixes this.

Simplify code for deparsing socketpair

Instead of fixing a typo programmatically, just spell it correctly to
begin with.  This should make things just slightly faster.

check existence of headers and libs for WinCE in Makefile.ce

Macro LIBC was used since day 1 of WinCE port (commit e1caacb4fd ), but
never before defined. On Desktop Win32 Perl, LIBC is msvcrt.lib, so fix
corelibc/msvcrt to be LIBC and not part of CELIBS. Then use LIBC in a
sanity check. Sanity checks will give an error message, vs running the
C compiler and geting cryptic messages about unknown .hs and random
missing symbols.

fix chop formats with non PV vars

[perl #119847],  [perl #119849], [perl #119851]

Strange vars like ties, overloads, or stringified refs (and in recent
perls, pure NOK vars) would generally do the wrong thing in formats
when the var is treated as a string and repeatedly chopped, as in
^<<<~~ and similar. This would manifest itself in infinite loops, utf8
errors etc. A recent change that stopped a stringified NOK getting
converted into a POK made the same badness happen for plain NVs too.

This commit contains two main fixes. First, the chopping was done
using sv_chop(), which only worked on POK strings. If its !POK, we now do
sv_setpvn() instead, which is less efficient, but will ensure the right
thing is always done.

Secondly, we make sure that the sv is accessed only once per cycle,
doing s = SvPV(sv, len) or similar. After that, all access is done only
via s and len. One place was using SvPVX(sv), and several places
were using the sv for utf8<->byte length conversions, such as
sv_pos_b2u().

It turns out that all the complex utf8 handling could be enormously
simplified. Since the code that needed to do utf8/byte length conversions
already scanned the string looking for suitable split points (such as
spaces or \n or \r), it was easiest to include any utf8 processing in the
same loop - i.e. incrementing s by UTF8SKIP(s) each time, but incrementing
the character count by 1.

The original diagnosis and reporting of this issue was done by Nicholas
Clark, who also supplied most of the tests.

pp_formline(): document switch cases

The individual ops (such as FF_END) of the format bytecode are documented
in form.h; appned those descriptive texts also to the individual 'case
FF_END:' lines in pp_formline, to make navigation easier. Also ensure
there's a blank line before each 'case'.

No functional changes.

Synology support now more explicit

Johan Vromans tested the changes on DS413. The changes I added before
are more Synology specific (though perhaps not only appropriate for
Synology) but at least wider than just armv5tel

[perl #75156] fix the return value and bits for removing a closed fh

[perl #75156] tests for deleting a closed handle from IO::Select

fix multi-eval of Perl_custom_op_xop in XopENTRY

Commit 1830b3d9c8 introduced a flaw where XopENTRY calls
Perl_custom_op_xop twice to retrieve the same XOP *. This is inefficient
and causes extra machine code. Since I found no CPAN or upstream=blead
usage of Perl_custom_op_xop, and its previous docs say it isn't 100%
public, it is being converted to a macro.

Most usage of Perl_custom_op_xop is to conditionally fetch a member of the
XOP struct, which was previously implemented by XopENTRY. Move the XopENTRY
logic and picking defaults to an expanded version of Perl_custom_op_xop.
The union allows Perl_custom_op_get_field to return its result in 1
register, since the union is similar to a void * or IV, but with the
machine code overhead of casting, if any, being done in the callee
(Perl_custom_op_get_field), not the caller. Perl_custom_op_get_field can
also return the XOP * without looking inside it to implement
Perl_custom_op_xop.

XopENTRYCUSTOM is a wrapper around Perl_custom_op_get_field with
XopENTRY-like usage.

XopENTRY is used by the OP_* macros, which are heavily used (but rarely
called, since custom ops are rare) by Perl lang warnings system. The
vararg warning arguments are usually evaluted no matter if the warning
will be printed to STDERR or not. Since some people like to ignore warnings
or run no strict; and warnings branches are frequent in pp_*, it is
beneficial to make the OP_* macros smaller in machine code. The design
of Perl_custom_op_get_field supports these goals.

This commit does not pass judgement on Ben Morrow's unclear public or
private API designation of Perl_custom_op_xop, and whether
Perl_custom_op_xop should deprecated and removed from public API. It was
trivial to leave a form of Perl_custom_op_xop in the new design.

XOPe enums are identical to XOPf constants so no conversion has to be
done between the field selector parameter and the field flag to test
in machine code.

ASSUME and NOT_REACHED are being introduced. The closest to the 2
previously was "assert(0)". Perl has not used ASSUME or CC specific
versions of it before. Clang, GCC >= 4.5, and Visual C are supported. For
completeness, ARMCC's __promise was added, but Perl is not known to have
any support for ARMCC by this commiter.

This patch is part of perl #115032.

Update Unicode-Collate to CPAN version 1.02

  [DELTA]

1.02  Sun Nov 10 18:39:37 2013
    - POD: fix [rt.cpan.org #90170] about iso-8859-1 letters in pod.
      E<> is used for the compatibility with perl 5.6.1 and possibly EBCDIC.
    - 1.01 forgot to increase the version number of CJK/Korean.pm.
    - modified tests: cjkrange.t, compatui.t, hangtype.t, illegal.t,
      loc_ja.t, loc_ta.t, overcjk0.t, overcjk1.t, view.t in t.

op.c: Factor out common entersub-building code

This same incantation occurs four times, though the readpipe variant
was slightly different.  The only difference was the lack of a scalar
flag on a null op, which makes no difference:

-           <1> ex-rv2cv sK ->-
5              <$> gv(*require) s ->6

-           <1> ex-rv2cv K ->-
5              <$> gv(*readpipe) s ->6

So I did not include the scalar() call, as it was unnecessary.  Also,
I changed op_append_elem to newLISTOP, since the former calls the lat-
ter anyway in these cases.

Fix deparsing of glob(my $x) and CORE::glob

A git bisect run like this:

$ ../perl.git/Porting/bisect.pl --start=v5.12.0 --end=v5.18.0 -e 'use B::Deparse; die if new B::Deparse->coderef2text(sub{glob my $x}) =~ /</'

points to v5.13.8-86-gd1bea3d as being the commit that cause it to
output <my $x>.

But my local 5.14.4 installation still outputs glob(my $x), so I am
not sure which commit is responsible.  I suspect it changed multi-
ple times.

In any case, B::Deparse was expecting the argument to pp_glob always
to be a string, which is certainly not guaranteed.

This commit also causes CORE::glob to be deparsed correctly.  glob is
one of those oddities like require that gets only half-overridden by
overrides.  In this particular case the built-in pp_glob is still
used, but takes a different code path depending on whether it was pre-
fixed with CORE::.  So, while glob is a strong keyword, it needs to be
treated as a weak one for deparsing purposes.

Stop open fh, ">>", \$undef from warning

$ ./perl t/TEST ../cpan/Test-Simple/t/subtest/bail_out.t
t/../cpan/Test-Simple/t/subtest/bail_out ... Use of uninitialized value in open at /Users/sprout/Perl/perl.git-copy/cpan/Test-Simple/../../lib/Test/Builder.pm line 1895.
ok
All tests successful.
u=0.01  s=0.00  cu=0.09  cs=0.01  scripts=1  tests=2

Notice the uninitialized value.

$ ./perl -Ilib -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'
Use of uninitialized value $x in open at -e line 1.
$ perl5.18.1 -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'

I caused that in v5.19.5-44-g5a2bc23:

$ ../perl.git/Porting/bisect.pl --start=045071eede --end=blead -e 'use warnings FATAL=>"uninitialized"; open $fh, ">>", \$x'
...
5a2bc23bfe5dc60ff957cb44ffaa57668d56d238 is the first bad commit
commit 5a2bc23bfe5dc60ff957cb44ffaa57668d56d238
Author: Father Chrysostomos <sprout@cpan.org>
Date:   Fri Oct 25 06:15:30 2013 -0700

    Better fix for #119529

op.c: Remove unused var

From 2186f87343.

perldiag: Two minor tweaks

One typo and one copy-and-paste error.

perl.c: White space only

Properly indent a few lines

numeric.c: White-space only

Properly indent the branch of an 'if'.

regexec.c: Fix compiler warning

We add an #ifdef DEBUGGING around a variable declaration, as that
variable actually only gets used in DEBUGGING compiles.

make perl core quiet under -Wfloat-equal

The gcc option -Wfloat-equal warns when two floating-point numbers
are directly compared for equality or inequality, the idea being that
this is usually a logic error, and that you should be checking that the
values are instead very near to each other.

perl on the other hand has lots of reasons to do a direct comparison.

Add two macros, NV_eq_nowarn(a,b) and NV_eq_nowarn(a,b)
that do the same as (a == b) and (a != b), but without the warnings.
They achieve this by instead doing (a < b) || ( a > b).
Under gcc at least, this is optimised into the same code as the direct
comparison.

The are three places that I've left untouched, because they are handling
NaNs, and that gets a bit tricky. In particular (nv != nv) is a test for a
NaN, and replacing it with (< || >) creates signalling NaNs (whereas ==
and != create quiet NaNs)

porting/diag.t: restrict what's a warn function

add a couple of judicious \b's so that while warn() etc are seen
as calls to a warn-related function, this_is_not_a_warn() etc aren't.

This is needed for the next commit which will introduce the macro
NV_ne_nowarn().

perldiag: Remove ‘The %s feature...’

The idea when this was added was for ‘use feature’ to warn when
an experimental feature was enabled.  Things didn’t turn out that
way.  Only lexical subs follow that wording, and they have their
own entry in perldiag, so this one is unnecessary.

toke.c: Remove unnecessary assignment

LOP returns, so the value of orig_keyword is not used after this.

[Merge] Make &CORE:: subs respect vmsish hints

Most lexical hints are stored in the statement’s nextstate(ment)
op (aka cop or control op).  That op is available at run time as
PL_curcop, while the current op being executed is PL_op.

&CORE:: subs intentionally lack a nextstate op so they can see the
hints in the caller’s nextstate op.

Two vmsish hints were being stored in the current op, so &CORE::exit()
would not respect those hints, as &CORE::exit() executes the *same*
exit op each time.

This branch moves those hints to the nextstate op, so that &CORE::exit
behaves the same way as exit().

Make &CORE::exit respect vmsish exit hint

by removing the hint from the exit op itself and just having pp_exit
look in the cop hint hash, where it is already stored (as a result of
having been in %^H at compile time).

&CORE:: subs intentionally lack a nextstate op (cop) so they can see
the hints in the caller’s nextstate op.

Update dump.c for the exit->nextstate hush hint move

Update B::Concise for the exit->nextstate hush hint move

Fix &CORE::exit/die under vmsish "hushed"

This commit makes them behave like exit and die without the ampersand
by moving the OPpHUSH_VMSISH hint from exit/die op to the current
statement (nextstate/cop) instead.  &CORE:: subs intentionally lack a
nextstate op, so they can see the hints in the caller’s nextstate op.

Teach B::Concise about VMS hushed flag

Failing tests for &CORE::exit/die with vmsish

Fix pod screwup in a05ea1cf8be

Thanks to Daniel Dragan for pointing it out.

Long verbatim pod line in INSTALL

Consistent spaces after dots in sv.c apidocs

POD-only mention sv_setsv does get magic but not set magic

Warn for all uses of %hash{...} in scalar cx

and reword the warning slightly.

See <20131027204944.20489.qmail@lists-nntp.develooper.com>.

To avoid getting a warning about scalar context for ‘delete %a[1,2]’,
which dies anyway, I stopped scalar context from being applied to
delete’s argument.  Scalar context is not meaningful here anyway, and
the context is not really scalar.

This also means that ‘delete sort’ no longer produces a warning about
scalar context before dying, so I added a test for that.

Make _charnames comparison null-safe

This comparison in toke.c checks whether the charnames translators is
the core’s own and, if so, skips certain validation checks.

Charnames translators coming from any package beginning with
"_charnames\0" would also be exempt from the checks, because the name
comparison stopped at the first null.

Stop lexical CORE sub from interfering with CORE::

The way CORE:: was handled in the lexer was convoluted.

CORE was treated initially as a keyword, with exceptions in the lexer
to make it behave correctly.  If it turned out not to be followed
by ::, then the lexer would fall back to treating it as a bareword
or sub name.

Before even checking for a keyword, the lexer looks for :: and goes
to the bareword/sub code.  But it made a special exception there
for CORE::.

In the end, treating CORE as a keyword recognized by the keyword()
function requires more special cases than simply special-casing CORE::
in toke.c.

This fixes the lexical CORE sub bug, while reducing the total num-
ber of lines.

toke.c: Remove dead code handling <FH> //

A few lines of code added by this commit:

commit 6f33ba736d46c2f5bfdb2405fd09d82ec18a1d07
Author: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Date:   Sun Aug 25 18:42:46 2002 +0000

    Fix parsing problems with the // operator.
    Make // able to follow various unary operators used without
    arguments or parens (shift, pop, getc, pos, readline,
    readlink, undef, umask, and the filetest operators), as
    well as the <FH> operator.

were already unreachable when they were added, specifically the code
for handling // after <FH> (which is fortunate, because XTERMORDORDOR
after <FH> would break <FH>+1).

S_scan_inputsymbol sets pl_yylval.ival to OP_NULL, since it has
already created the ops; it has done so since perl 5.000.  So this
branch is never reached when parsing <FH>.

The if-block containing these lines has had ‘|| op_type ==
OP_READLINE’ since perl 5.000, which has also always been redundant
for the same reason.

threads::shared: fix compiler warning

make the file name stored in the lock on debugging builds
be const char* rather than char*, so that passing __FILE__ doesn't give
lots of

    shared.xs:1287:323: warning: deprecated conversion from string
    constant to 'char *' [-Wwrite-strings]

t/x2p/find2perl.t: expand output

Currently there is one ok() per test case; split that into 4 ok()s
per case, so that different sorts of failures can be differentiated
(i.e. ability to: run find2perl, run its output, run find, and compare the
outputs.)

This version bump also got lost in the merge

Guess there will always be ways in git to explore ...

pod fix

I did this in the merge and the tests passed!

Note (new) platform support

Do I need to add some more extensive reading in README.arm or the like?

Enhance INSTALL instructions for missing libraries

With symlinks in /lib m and crypt are are no longer exceptions

Configure will only look for libfoo.so. If libfoo.so.{num} exists and
libfoo.so does not, make a symbolic link and start over. For this
Synology DS213, I needed

 # cd /lib
 # ln -s libm.so.6 libm.so
 # ln -s libcrypt.so.1 libcrypt.so

Search for errno.h in more (semi)default locations

hints for CPU model Marvell Kirkwood mv6282 ARMv5te

Tested on Synology DS213

architecture arm5tel seems to differ from other ARM

On Synology, all development is installed under /opt
LANG settings other than C are not (really) supported

Update B-Debug to CPAN version 1.19

  [DELTA]

  1.19 2013-11-07 rurban
    * install into site (again) since 5.12
    * support lexical subs, NAME instead of GV.
    * fix double SV FLAGS
    * fix wrong xpv_cur, add xpv_len

silence spurious 'may be uninitialized' warnings

-Wmaybe-uninitialized isn't smart enough, so explicitly NULL a couple
of vars to keep it happy.

remove some unused vars from op.c and toke.c

More stack for pat_thr.t on VMS as well.

Follow-up to 66478a1b30 and 58b6d14529f.

Commit 1735f6f53ca19f99c6e9e39496c486af323ba6a8 started to escape all
back-slashes which breaks case when lexicon translations contain substition
and literals with eval-non-safe characters. E.g.  these translations:

"[_1]foo\\n\n" => "[_1]bar\\n\n",
'[_1]foo\n' => '[_1]aÄ\9ba\n',

got doubled back-slashes on the maketext() output.

This patch de-escapes escaped backslashes if the literal is compiled as
function argument.

Fixes RT #120457.

perlfunc: Clarify verbatim table

When I read what was here before this patch, I thought there was a typo,
as there was no entry in column 1 for several rows.  Instead, what was
meant was that the item in column 1 row 1 was supposed to be dittoed
into the following rows.  I used the solution employed in Camel 4,
which is to repeat that item in each row it applies to.

perlfunc.pod: long verbatim lines

Fix qx, `` and <<`` overrides

This resolves two RT tickets:
• #115330 is that qx and `` overrides do not support interpolation.
• #119827 is that <<`` does not support readpipe overrides at all.

The obvious fix for #115330 fixes #119827 at the same time.

When quote-like operators are parsed, after the string has been
scanned S_sublex_push is called, which decides which of two paths
to follow:
1) For things not requiring interpolation, the string is passed to
   tokeq (originally called q, it handles double backslashes and back-
   slashed delimiters) and returned to the parser immediately.
2) For anything that interpolates, the lexer enters a special inter-
   polation mode (LEX_INTERPPUSH) and goes through a more complex
   sequence over the next few calls (e.g., qq"a.$b.c" is turned into
  ‘stringify ( "a." . $ b . ".c" )’).

When commit e3f73d4ed (Oct 2006, perl 5.10) added support for overrid-
ing `` and qx with a readpipe sub, it did so by creating an entersub
op in toke.c and making S_sublex_push follow path no. 1, taking the
result if tokeq and inserting it into the already-constructed op tree
for the sub call.

That approach caused interpolation to be skipped when qx or `` is
overridden.  Furthermore it didn’t touch <<`` at all.

The easiest solution is to let toke.c follow its normal path and
create a backtick op (instead of trying to half-intercept it), and
to deal with override lookup afterwards in ck_backtick, the same way
require overrides are handled.  Since <<`` also turns into a backtick
op, it gets handled too that way.

Split ck_open into two functions

It is used for two op types, but only a small portion of it applies
to both, so we can put that in a static function.  This makes the
next commit easier.

gv.c:gv_try_downgrade: Use hv_fetchhek

Unlike hv_fetch, this also passes the precomputed hash, saving
hv_common from having to recalculate it.

toke.c: Remove unnecessary UTF check

In this particular branch, the value of PL_tokenbuf will always
be a built-in keyword; i.e., pure ASCII.  So there is no need to
do a utf8 check.

Put common override code into gv_override

When I moved the three occurrences of this code in op.c into a static
function, I did not realise at the time that it also occurred thre
etimes in toke.c.

So now it is in a new non-static function in gv.c.

Only two of the instances in toke.c could be changed to use this func-
tion, as the otherwise is a little different.  I couldn’t see a simple
way of factoring its requirements in.

Fix readline overriden with a constant

<> doesn’t take into account that some subs are stored in a more
lightweight form than usual.  These two programs should behave the
same way, but, as you can see below the __END__ markers, the output is
different:

use constant foo=>1;
BEGIN { *{"CORE::GLOBAL::readline"} = \&{"foo"}; 1}
warn <a>
__END__
Warning: something's wrong at - line 3.

use constant foo=>1;
BEGIN { *{"CORE::GLOBAL::readline"} = \&foo; 1}
warn <a>
__END__
Too many arguments for main::foo at - line 3, at end of line
Execution of -e aborted due to compilation errors.

The latter is the correct behaviour.  The only different is \&{"foo"}
vs \&foo, the first of which triggers an optimisation.

S_scan_inputsymbol in toke.c needs to take the optimisation into
account (that stash entries are not necessarily globs but can be
upgraded to such).

Allow CORE::GLOBAL:: subs in general to be aliased to consts

$ perl5.8.8 -e 'use constant foo=>1; BEGIN { *{"CORE::GLOBAL::time"} = \&{"foo"};1} warn time'
1 at -e line 1.
$ perl5.10.1 -e 'use constant foo=>1; BEGIN { *{"CORE::GLOBAL::time"} = \&{"foo"};1} warn time'
1383661397 at -e line 1.

When the storage of constants was optimised in perl 5.10, the code that
checks for global overrides was not updated to account.

Stop gv_try_downgrade from anonymising referenced CVs

I keep discovering ways in which gv_try_downgrade, which is supposed
to be an optimisation, changes observable behaviour even without look-
ing at the stash.

This one had me confused at first:

$ ./perl -Ilib -e 'use constant foo=>1; BEGIN { $x = \&foo } undef &$x; $x->()'
Undefined subroutine called at -e line 1.
$ ./perl -Ilib -e 'use constant foo=>1; BEGIN { $x = \&{"foo"} } undef &$x; $x->()'
Undefined subroutine &main::foo called at -e line 1.

Notice how the first example (where gv_try_downgrade kicks in)
shows no name in the error message.  This only happens on non-
threaded builds.

What’s happening is that, when the BEGIN block is freed, the GV op
corresponding to &foo get freed, triggering gv_try_downgrade, which
checks to see whether it can downgrade the GV to a simple reference
to a constant (the way constants are stored by default).  It then pro-
ceeds to do that, so the GV qua GV ceases to exist, and the CV gets
automatically anonymised as a result (the same thing happens with
‘$x = \&{"foo"}; Dump $x; delete $::{foo}’, but legitimately in
that case).

The solution here is to check the reference count on the CV before
downgrading the GV.  If the CV’s reference count > 1, then we should
leave it alone.

perlfunc: update require() pseudocode

RT #120292

The entry for require() in perlfunc has a perl function that's supposed to
illustrate how require works is rather out of date. In particular, the
fact that the search stops on EACCES wasn't incorporated, and the various
ways of it failing and reporting errors was inaccurate.

I also removed the explicit code for executing the 'do' in the caller's
package, and replaced it with just the comment 'but run in caller's
namespace', since the details were a bit obscure.

Finally, I re-indented it since it had strange 3-space indents

gv.c: Removed redundant len==1 check

When I added this in ea238638, I put the same code in the branches
for the main stash and other stashes.  In the main stash branch, this
occurs in a switch that is solely for one-character names, so checking
the length again is superfluous.

toke.c: Remove unnecessary SvRV null check

If SvROK is true, then SvRV will never be null.  (If it is, then
serious problems will occur elsewhere, as other code assumes this.)

Fix readpipe overriden with a constant

qx and `` don’t take into account that some subs are stored in a more
lightweight form than usual.  These two programs should behave the
same way, but, as you can see below the __END__ markers, the output is
different:

use constant foo=>1;
BEGIN { *{"CORE::GLOBAL::readpipe"} = \&{"foo"}; 1}
warn ``
__END__
Warning: something's wrong at - line 3.

use constant foo=>1; BEGIN { *{"CORE::GLOBAL::readpipe"} = \&{"foo"}; 1} warn ``
__END__
Too many arguments for CORE::GLOBAL::readpipe at - line 3, at end of line
Execution of -e aborted due to compilation errors.

The latter is the correct behaviour.¹  The only different is \&{"foo"}
vs \&foo, which triggers an optimisation.

S_readpipe_override in toke.c needs to take the optimisation into
account (that stash entries are not necessarily globs but can be
upgraded to such).

¹ Except that the sub name reported is unexpected.  Non-threaded
  builds give me that; threaded builds give me main::foo.  But that is
  a separate bug.