Update experimental to CPAN version 0.012

  [DELTA]

0.012     2014-10-12 12:10:06+02:00 Europe/Amsterdam
          Added lvalue references feature
Update B-Debug to CPAN version 1.22

  [DELTA]

1.22 2014-10-12 rurban
  * add 5.21.5 support: changed test, from blead for split optim.,
    added METHOP
  * print 0x00000000 as 0x0
  * add -d -MOd=Debug support
  * README: fixed copyright date
Update Test-Simple to CPAN version 1.001008

  [DELTA]

1.001008     Wed Oct 15 20:10:22:00 PST 2014
    * Updated Changes file

1.001007     Wed Oct 15 16:37:11:00 PST 2014
    * Fix subtest name when skip_all is used
perldelta for our declarations

f5b5c2a Simplify double-nextstate optimisation
5afbd73 Elide our($foo) from execution order in void cx
8717a76 op.c: Null list and pushmark in void cx
perldelta: reword an entry

It was not completely correct, and trying to get it correct is too
complicated.
podcheck.t: Make pod name check less sensitive

I regularly find myself ignoring the pod name failure after tweaking
the pod or rebasing and not re-running make.  ‘Known’ test failures
are not a good thing.
sv.c:sv_catsv: Remove null check

SvPV always returns something.  If it didn’t, we’d be crashing all
over the place, since most other code assumes it does.
Improve void varop optimisation

After eliding the varop, the optimisation added in 5afbd733 repro-
cesses the previous op if it is a nextstate op.  But it was doing this
by setting the current op to the one before the nextstate, so that the
o=o->op_next in the loop header would cause it to reprocess the next-
state in the next iteration.  So, if that nextstate op were at the
beginning of a subroutine, the optimisation would be skipped, and this
would still execute two nextstate ops in a row:

sub foo {
    our($a, $b);
    die;
}

So, instead, just use ‘goto’ to reprocess the op, and we can do it
even if there is no op before the nextstate.
[perl #122995] Hang with while(1) in a sub-list

It was hanging at compile time in some cases, e.g.:

sub foo { () = ($a, my $b, ($c, do { while(1) {} })) }

The optimisation added in 5.20 to turn list+pushmark into null ops
when they are in list context (effectively making ($a,($b,$c)) equiva-
lent to ($a,$b,$c) with regard to which ops are executed) followed
op_next pointers to find the last op that was a kid of the sublist.

You can’t just follow op_next pointers like that, because it will loop
at compile time on infinite loops like while (1){}.

In this case, the last kid was being found in order to elide the erst-
while list op from the op_next chain, but that is not necessary, since
later OP_NULL handling takes care of it anyway.
e2a5b7204 made dVAR necessary also for unthreaded builds.
fix some recent compiler warnings

Currently DBVARMG_SINGLE is deffed to 0, so

    mg->mg_private >= DBVARMG_SINGLE

gives an 'always true' warning.

sv_magicext's last arg is supposed to to be I32, but ARGTARG is a U32 or
U64.
B::Concise: Dump private vars for null ops

This can be very helpful for debugging.  For null ops that were not
always null, output the private flags as we would for unnulled ops.
Skip padrange optimisation for one padop

cachegrind shows that padrange is marginally slower than pushmark+padsv
(<20141017140518.GF5204@iabyn.com>).
op.c: Change a pushre if into assert()
Allow void padrange even without nextstate

This allows the padrange optimisation to happen with code like this:

    my ($a, $b), our $c;

The padrange optimisation looks for:

    list
      pushmark
      padsv
      padsv
      ...
    nextstate

if it is in void context.

padsv pushes an sv on to the stack, and then nextstate resets the
stack.  padrange doesn’t bother pushing in void context, which is why
this optimisation was written this way.

However, there are various ops that don’t bother touching the stack in
void context, for efficiency; conversely, there are many that do for
simplicity’s sake.  In all cases, however, things pushed in void con-
text are subsequently reset, usually by list/nextstate/leavesub,
before they can accidentally become part of a list.  So whether pad-
range pushes SVs or not in void context is irrelevant, and it does not
matter whether there is a nextstate op.

Further, this optimisation also allowed:

  ex-list
    pushmark
    ...

pushmark and list ops cancel each other out in list and void context.
padrange does not push a mark in void context, so the list is removed
from the execution chain.  That was also happening for a nulled list,
which is incorrect, as that means a lone pushmark is being removed.  I
don’t believe ex-list+pushmark ever occurs in void context, but if it
does then this code was wrong.
Update Perl 5 Porter list archives.

For: RT # 122996
Use sv_catpvn instead of sv_catsv in doop.c:do_join

Bunchmarking shows that SvPV+sv_catpvn is faster that sv_catsv.  Why
exactly I don’t know, but perhaps fewer functions and flag checks
are the cause.
mention 'switch' is experimental in feature.pm

The other experimental features already have nice warnings in feature.pm
Rename lvalue references

Also correct the description of lvref magic.  When it was first added,
it was for list assignments only, but that soon changed.
perlref: \@hash{slices} = too