Sync Module-CoreList version after CPAN release
Update CPAN-Meta to CPAN version 2.142060

  [DELTA]

2.142060  2014-07-25 13:30:06-04:00 America/New_York

  [ADDED]

  - CPAN::Meta::Merge is a new class for merging two possibly overlapping
    instances of metadata. It will accept both CPAN::Meta objects and
    (possibly incomplete) hashrefs of metadata.
Update HTTP-Tiny to CPAN version 0.047

  [DELTA]

0.047     2014-07-29 14:09:05-04:00 America/New_York

    [CHANGED]

    - Updated Mozilla::CA module recommendation version to 20130114

    [FIXED]

    - Fixed t/00-report-prereqs.t when CPAN::Meta is not installed

0.046     2014-07-21 10:32:32-04:00 America/New_York

    [FIXED]

    - Empty header fields are now allowed; headers with the 'undef' value
      will be rendered as an empty header.

    [DOCUMENTED]

    - Updated HTTP/1.1 spec description from RFC 2616 to RFC 7230-7235

0.045     2014-07-19 23:17:28-04:00 America/New_York (TRIAL RELEASE)

    [FIXED]

    - Fixed t/002_croakage.t for various operating systems.
make "require" handle no argument more gracefully, and add tests

in Perl 5.14 the following segfaults:

    *CORE::GLOBAL::require = sub { }; eval "require";

in Perl 5.18

    perl -wle'eval "require";'

produces a spurious warning:

    Use of uninitialized value $_ in require at (eval 1) line 1.

In other perls:

    perl -e 'eval q/require $this/ or print $@'

produces:

    Null filename used at (eval 1) line 1.

The error message is crappy, totally unfit for a perl audience,
and the spurious warning is just confusing. There is no $_ in use
here, why do we warn about it.

It looks like 9e3fb20c fixed the segfault (by accident), and also
somehow meant that the "Null filename" error would not ever be
produced.

So this patch ditches the crappy error and replaces it with something
meaningful and informative, and tests that we do not regress and start
segfaulting again.
Fix tabs in MANIFEST
Avoid pack/unpack to produce the binary form of a utf8 string
Correct double mention of winpid_to_pid.

As reported by graham at wdlabs dot com.

For: RT #122430
Update CPAN-Meta-Requirements to CPAN version 2.126

  [DELTA]

2.126     2014-07-30 16:26:29-04:00 America/New_York

    [FIXED]

    - Fixed compatibility with version.pm 0.77

    [DOCUMENTED]

    - Minor documentation fixes

    [CHANGED]

    - Modernized distribution meta files
add --help to Porting/sync-with-cpan
Sync Config::Perl::V to version 0.21

 * Add tests for each major distribution since 5.6.2
 * Better detect build times
 * Sync with 5.20.1
Test file had been renamed. remove old cruft
t/op/coresubs.t: factor out an internal routine

This routine will be used in the next commit. I believe that the behaviour
of the tests remains unchanged after this commit.
Fix bug in inlining some CORE::* subs

As of 4aaa475724fbbc4ab2427743fa4d07a12e6ce0d9, when Perl compiles code like

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

the apparent call to "entangle" is replaced with an inlined invocation of
the "tie" builtin.

For unary ops, the OPf_SPECIAL flag was set on the generated inlined op iff
the op's argument was surrounded by parens. But that's incorrect for ops
which have their own interpretation of OPf_SPECIAL. In particular:

  keys, values, each
    OPf_SPECIAL is set for lvalue usage; this shows up when the compile-time
    argument is a reference to be subjected to the autoderef feature, and
    the run-time argument is an array ref. The existing tests didn't execute
    the code (and didn't combine inlining with array autoderefs), so didn't
    catch this case.

  delete, exists
    OPf_SPECIAL is set when the argument is an array element rather than a
    hash element; this doesn't directly cause any obvious problems, because
    pp_delete and pp_exists consider OPf_SPECIAL only when they've already
    determined that their argument is an array element, but it did break
    deparsing (because B::Deparse considers OPf_SPECIAL in all cases): the
    hash element argument got deparsed as an array element. Further, the
    inlining tests themselves rely on deparsing to ensure that the op was
    inlined. The existing inlining tests happened to use array elements, so
    didn't catch this problem.

This commit fixes those cases, by avoiding setting OPf_SPECIAL when inlining
an invocation of one of those ops. The list of op types is hard-coded; this
seems a little icky, but I don't see a better alternative.

I believe that no other ops are affected by this issue, but my confidence in
that statement isn't as high as it might be; it seems hard to work out
exactly which ops use OPf_SPECIAL.
regcomp.c: Don't read outside array bound

This code is only in DEBUGGING builds had an off-by-one error
that would read beyond the end of the array.  This commit also removes
a redundant test
Update Config::Perl::V to version 0.22
Update B-Debug to CPAN version 1.20

  [DELTA]
    1.20 2014-08-03 rurban
      * avoid exists on an array element (aaron crane)
Update perlfaq to CPAN version 5.0150045

  [DELTA]

5.0150045 Sun 3 Aug 2014 18:16:06 +0100
  * Improve example, use File::Spec (Brian Fraser)
  * Typo in perlfaq7 (Rares Aioanei, via shlomif)
  * Typo in perlfaq1 (Xaerxess)
Fix hint typo: No leading underscore in PERL_USE_SAFE_PUTENV

hints/solaris_2.sh generates a config.over script intended to add
PERL_USE_SAFE_PUTENV to ccflags, if it is not already present.  An extra
leading underscore in the check meant that the test always failed and
PERL_USE_SAFE_PUTENV always got added.
[perl #121404] tied hashes are different
Critical bugfix in module Safe (Opcode). Version increased, changelog and test added.

This example hacks outside environment:

package My::Controller;
use strict;

sub jopa { return "jopa\n"; }

package main;
use Safe;

my $s = new Safe;

my $ok = $s->reval(q{
    package My::Controller;
    sub jopa { return "hacked\n"; }

    My::Controller->jopa();
});

print My::Controller->jopa();