Update Term-UI to CPAN version 0.32

  [DELTA]

  Changes for 0.32        Sat Nov 10 11:00:31 GMT 2012
  =====================================================
  * Add a delimiter to a prompt that doesn't have a default
    (Tommy Stanton)
Update CGI to CPAN version 3.62

  [DELTA]

  Version 3.62, Nov 9th, 2012

    [INTERNALS]
    - Changed how the  deprecated endform function was defined for compatibilty
      with the development version of Perl.
    - Fix failures in t/tmpdir.t when run as root
      https://github.com/markstos/CGI.pm/issues/22, RT#80659)

    - Made it possible to force a sorted order for things like hash
      attributes so that tests are not dependent on a particular hash
      ordering. This will be required in modern perls which will
      change the ordering per process. (Yves, RT#80659)
add $B::overlay feature

This allows you to alter the read-only "view" of an optree, by making
particular B::*OP methods on particular op nodes return customised values.
Intended to be used by B::Deparse to "undo" optimisations, thus making it
easier to add new optree optimisations without breaking Deparse.
pad_free(): don't clear SVs_PADSTALE

pad_free() clears the SVs_PADTMP bit. Since that bit is now shared
with SVs_PADSTALE, that gets cleared on state vars. It didn't matter up
till now, but the next commit will start optimising away pad ops, and
op_null() will call pad_free() which would clear the SVs_PADSTALE bit.

So only clear SVs_PADTMP/SVs_PADSTALE for non-lexical var ops.
add padrange op

This single op can, in some circumstances, replace the sequence of a
pushmark followed by one or more padsv/padav/padhv ops, and possibly
a trailing 'list' op, but only where the targs of the pad ops form
a continuous range.

This is generally more efficient, but is particularly so in the case
of void-context my declarations, such as:

    my ($a,@b);

Formerly this would be executed as the following set of ops:

    pushmark  pushes a new mark
    padsv[$a] pushes $a, does a SAVEt_CLEARSV
    padav[@b] pushes all the flattened elements (i.e. none) of @a,
              does a SAVEt_CLEARSV
    list      pops the mark, and pops all stack elements except the last
    nextstate pops the remaining stack element

It's now:

    padrange[$a..@b] does two SAVEt_CLEARSV's
    nextstate        nothing needing doing to the stack

Note that in the case above, this commit changes user-visible behaviour in
pathological cases; in particular, it has always been possible to modify a
lexical var *before* the my is executed, using goto or closure tricks.
So in principle someone could tie an array, then could notice that FETCH
is no longer being called, e.g.

    f();
    my ($s, @a); # this no longer triggers two FETCHES
    sub f {
	tie @a, ...;
	push @a, 1,2;
    }

But I think we can live with that.

Note also that having a padrange operator will allow us shortly to have
a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple
individual SAVEt_CLEARSV's.
add SAVEt_CLEARPADRANGE

Add a new save type that does the equivalent of multiple SAVEt_CLEARSV's
for a given target range. This makes the new padange op more efficient.
reindent block in leave_scope

The previous commit added a loop round a block of code; now increase
the indent of the body of the loop.
padrange: handle @_ directly

In a construct like
    my ($x,$y) = @_
the pushmark/padsv/padsv is already optimised into a single padrange
op. This commit makes the OPf_SPECIAL flag on the padrange op indicate
that in addition, @_ should be pushed onto the stack, skipping an
additional pushmark/gv[*_]/rv2sv combination.

So in total (including the earlier padrange work), the above construct
goes from being

    3  <0> pushmark s
    4  <$> gv(*_) s
    5  <1> rv2av[t3] lK/1
    6  <0> pushmark sRM*/128
    7  <0> padsv[$x:1,2] lRM*/LVINTRO
    8  <0> padsv[$y:1,2] lRM*/LVINTRO
    9  <2> aassign[t4] vKS

to

    3  <0> padrange[$x:1,2; $y:1,2] l*/LVINTRO,2 ->4
    4  <2> aassign[t4] vKS
Consolidate adjacent padrange ops

In something like

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

when converting $c,$d into a padrange op, check first whether we're
immediately preceded by a similar padrange (and nextstate) op,
and if so re-use the existing padrange op (by increasing the count).
Also, skip the first nextstate and only use the second nextstate.

So

    pushmark;
    padsv[$a]; padsv[$b]; list;
    nextstate 1;
    pushmark;
    padsv[$c]; padsv[$c]; list;
    nextstate 2;

becomes

    padrange[$a,$b]
    nextstate 1;
    pushmark;
    padsv[$c]; padsv[$c]; list;
    nextstate 2;

which then becomes

    padrange[$a,$b,$c,$d];
    nextstate 2;
Consolidate any single pad ops after a padrange

Given something like
    my ($a,$b); my $c; my $d;
then after having detected that we can create a padrange op for $a,$b,
extend it to include $c,$d too.

Together with the previous commit that consolidates adjacent padrange
ops, this means that any contiguous sequence of void 'my' declarations
that starts with a list (i.e. my ($x,..) rather than my $x) will
all be compressed into a single padrange op. For example

    my ($a,$b);
    my @c;
    my %d;
    my ($e,@f);

becomes the two ops

    padrange[$a;$b;@c;%d;$e;@f]
    nextstate

The restriction on the first 'my' being a list is that we only ever
convert pushmarks into padranges, to keep things manageable (both for
compiling and for Deparse). This simply means that

    my $x; my ($a,$b); my @c; my %d; my ($e,@f)

becomes

    padsv[$x]
    nextstate
    padrange[$a;$b;@c;%d;$e;@f]
    nextstate
fix optree_misc.t test after smoke

Some of the unicode setting in a smoke environment sets the open hints
output on nextstate lines.
ext/B/t/OptreeCheck.pm: fix hint stripping

The code that strips hints from a nextstate couldn't handle
the 'next' pointer being '-', e.g. v:>,<,% ->-
[MERGE] add PADRANGE op and $B::overlay

This commit implements three optimisations and one new feature.

The new feature is $B::overlay, which can be set to a hash ref, indexed by
op address, that allows you to override the values returned by the various
B::*OP methods for a particular op. This specifically allows Deparse to be
tricked into seeing a pre-optimisation view of the optree, and so makes
adding new optimisations (like the one in this commit) a lot easier.

As regards optimisations: first, a new save type is added:
SAVEt_CLEARPADRANGE, which is like SAVEt_CLEARSV but specifies a range of
targs to be cleared. The save type, target base and range all fit within a
single integer pushed on the save stack.

Second, a pushmark followed by one or more pad[ahs]v ops (and possibly
some mixed-in null, list and nextstate ops) will sometimes be replaced by
a single padrange op. Like other pad ops, this specifies a targ, but in
addition the bottom 7 bits of op_private indicate a target range.
pp_padrange has two main actions: with OPpLVAL_INTRO, it pushes a
SAVEt_CLEARPADRANGE onto the save stack and turns off SvPADSTALE on all
the lexicals; and in non-void context, it pushes all the lexicals onto the
stack.

Third, for the specific case of the construct my(...) = @_, the
ops to push @_ onto the stack (pushmark/gv[*_]/rv2sv) are skipped,
and the OPf_SPECIAL flag on the padrange op is set: this tells
pp_padrange to push @_ directly.

Note that not sequences of pad ops are consolidated into a single
padrange op; the chief constraints are that:

* they must form a list (i.e. start with pushmark);
* the targs must form a contiguous range;
* the flags of the ops must all be similar; e.g. all INTRO or all not,
   all void or all not, etc;
* only a subset of flags are allowed; e.g. we don't optimise with
  OPpPAD_STATE or OPpMAYBE_LVSUB present.

For the specific case of void/INTRO, we consolidate across nextstate
boundaries (keeping only the last nextstate); i.e.

    my ($a,$b); my @c; my (%d,$e,$f)

becomes a single padrange op. Note that the padrange optimisation is
particularly efficient for the void/INTRO combination: formerly,
my($a,$b,@c,%d); would be compiled as

    pushmark; padsv[$a]; padsv[$b]; padav[@c]; padhv[%d]; list; nextstate

which would have the effect of pushing $a, $b onto the stack, then
pushing the (non-existent) elements of @c, then pushing the %d HV; then
pp_list would pop all the elements except the last, %h; finally, nextstate
would pop %h.  Instead, padrange skips all the pushing and popping in void
context.  Note that this means that there is one user-visible change caused
by this optimisation:

    f();
    my @a;
    sub f { tie @a, ...; push @a, .... }

Here, @a is tied and already has elements by the time the 'my @a' is
executed; formerly, FETCH would be called repeatedly to push the elements
of @a onto the stack, then they would all be popped again at the end of the
'my @a' statement; now FETCH is never called.

The optimisation itself is implemented by converting the initial pushmark
op into a padrange, and updating its op_next. The skipped ops are *not*
cleared; this makes it easier for S_find_uninit_var() and Deparse.pm to do
their stuff. Deparse is implemented by using the new $B::overlay facility
to make the padrange op look like a pushmark op again; the rest of the
Deparse code just sees the original unoptimised optree and so doesn't
require any knowledge of the padrange op.
add 5.12.5 epigraph
Add the 5.12.5 perldelta
add 5.12.5 to perlhist
The v5.16.2 updates had disappeared (if they were there in the first place) reinstate
Module-CoreList updated to 2.77

  - Documented decprecated_in() function
  - Updated with v5.16.2 data
  - Updated with v5.12.5 data
  - Updated POD to reflect included perl data
fix NAME of perl5125delta.pod
README: add pointer to super-quick patch quide