perldiag: ‘Scalars leaked’ is a default warning
perldiag: ‘Unbalanced string table’ is a default warning
Fix %vd with alpha version

There are five problems with it:

First, this warning is not suppressible, even with -X:

$ perl -Xe' sprintf "[%vd]\n", new version v1.1_1'
vector argument not supported with alpha versions at -e line 1.

To keep the behaviour as close as possible to what it was already
without the incorrect behaviour, I have made it a default warning.

Secondly, putting it in the internal category does not make sense.
internal is a subset of severe, and contains warnings that indicate
internal inconsistencies, like ‘Scalars leaked’ and ‘Unbalanced string
table refcount’.  It should be in the printf warnings category.

Thirdly, if we turn warnings on explicitly, we see this:

$ perl -we '() = sprintf "[%vd]\n", new version v1.1_1'
vector argument not supported with alpha versions at -e line 1.
Invalid conversion in printf: "%v" at -e line 1.

%vd is not invalid.  That warning is bogus.

Fourthly, %vd itself gets output when fed an alpha version:

$ perl -Xe 'printf "[%vd]\n", new version v1.1_1'
vector argument not supported with alpha versions at -e line 1.
[%vd]

If an argument is missing or invalid or what have you, the %-format
itself should not be output.  An empty string makes the most sense.

Fifthly, it leaks memory.  Run this and watch memory usage go up:

$ perl -e '
   warn $$; $SIG{__WARN__} = sub {}; $v = new version v1.1_1;
   sprintf "%vd", $v while 1
'

It does savesvpv before shortcircuiting for alphas.  But the corres-
ponding Safefree comes after the shortcircuiting, which skips it.
sv.c: %vd printf format microöptimisation

The %vd printf format does not need to make two copies of a version
object’s stringification or stringify the object twice.
perlhacktips.pod: readonly ops update (again)
perldiag: ‘Attempt to free unreffed scalar’ is S
perldiag: 13 years for reserved word deprec. is enough

Use of ‘our’ (which was not a keyword yet) was deprecated in 1997 in
commit 85b81015bd, so that it could be used as a keyword later.

‘our’ variables were introduced in 1999 in commit 77ca0c92d2c, remov-
ing the deprecation warning.

The notice in perldiag survived, ...till now.
Make (caller $n)[9] respect std warnings

In commit 7e4f04509c6 I forgot about caller.  This commit makes the
value returned by (caller $n)[9] assignable to ${^WARNING_BITS} to
produce exactly the same warnings settings, including warnings con-
trolled by $^W.
Stop lexical warnings from turning off deprecations

Some warnings, such as deprecation warnings, are on by default:

$ perl5.16.0 -e '$*'
$* is no longer supported at -e line 1.

But turning *on* other warnings will turn them off:

$ perl5.16.0 -e 'use warnings "void"; $*'
Useless use of a variable in void context at -e line 1.

Either all warnings in any given scope are controlled by lexical
hints, or none of them are.

When a single warnings category is turned on or off, if the warn-
ings were controlled by $^W, then all warnings are first turned on
lexically if $^W is 1 and all warnings are turned off lexically
if $^W is 0.

That has the unfortunate affect of turning off warnings when it was
only requested that warnings be turned on.

These categories contain default warnings:

ambiguous
debugging
deprecated
inplace
internal
io
malloc
utf8
redefine
syntax
glob
inplace
overflow
precedence
prototype
threads
misc

Most also contain regular warnings, but these contain *only*
default warnings:

debugging
deprecated
glob
inplace
malloc

So we can treat $^W==0 as equivalent to qw(debugging deprecated glob
inplace malloc) when enabling lexical warnings.

While this means that some default warnings will still be turned off
by ‘use warnings "void"’, it won’t be as many as before.  So at least
this is a step in the right direction.

(The real solution, of course, is to allow each warning to be turned
off or on on its own.)
Increase $warnings::VERSION to 1.14
Prevent assertion failure with ‘no a a 3’

This particular syntax error, whittled down from ‘no if $] >= 5.17.4
warnings => "deprecated"’ (which contains a type), causes the parser
to try to free an op from the new sub (for the BEGIN block) after
freeing the new sub.

This happens on line 526 of perly.c.  It should not be necessary for
the parser to free the op at this point, since after an error any ops
owned by incomplete subs’ slabs will be freed.

I’m leaving the other three instances of op_free in perly.c in place,
at least for now, since there are cases where the forced token stack
prevents ops from being freed when their subs are.
pp_ctl.c:caller: Remove obsolete comment

This was added in f3aa04c29a, but stopped being relevant in
d5ec2987912.
cop.h: Remove obsolete comment

623e6609 (2 Apr 2006) added this to cop.h:

+/* FIXME NATIVE_HINTS if this is changed from op_private (see perl.h)  */
+#define CopHINTS_get(c)                ((c)->op_private + 0)
+#define CopHINTS_set(c, h)     STMT_START {                            \
+                                   (c)->op_private                     \
+                                        = (U8)((h) & HINT_PRIVATE_MASK); \
+                               } STMT_END
+

d5ec2987 (20 May 2006) made this change, ignoring the FIXME:

 /* FIXME NATIVE_HINTS if this is changed from op_private (see perl.h)  */
-#define CopHINTS_get(c)                ((c)->op_private + 0)
+#define CopHINTS_get(c)                ((c)->cop_hints + 0)
 #define CopHINTS_set(c, h)     STMT_START {                            \
-                                   (c)->op_private                     \
-                                        = (U8)((h) & HINT_PRIVATE_MASK); \
+                                   (c)->cop_hints = (h);               \
                                } STMT_END

There is nothing to be fixed here, as vmsish.h uses ->op_private
directly, instead of using the CopHINTS macros.  Even having caller
return cop_hints instead of op_private doesn’t hurt, as newly-created
cops copy the vms hints from PL_hints to op_private.  So assigning
(caller $n)[8] to $^H will still work.
method.t: Test more method-BLOCK edge cases
method.t: Add basic tests for SUPER
Make SUPER:: in main less sensitive

$ perl -e '$main::SUPER::; sub bar::bar{} @ISA = bar; main->SUPER::bar'
$ perl -e '$SUPER::; sub bar::bar{} @ISA = bar; main->SUPER::bar'
Can't locate object method "bar" via package "main" at -e line 1.

(That’s 5.10.1.  More recent perls say package "SUPER".)

The only differnce that $SUPER:: variable makes is the name of
the SUPER:: package.  It ends up being called SUPER instead of
main::SUPER.

This causes problems because gv_fetchmeth_pvn, seeing a package end-
ing in ::SUPER, strips off the ::SUPER before doing isa lookup.

But SUPER does not end in ::SUPER, so this commit adjusts
gv_fetchmeth_pvn to account.
Make SUPER::method calls work in moved stashes

BEGIN {
  *foo:: = *bar::;
  *bar:: = *baz;
}
package foo;
@ISA = 'door';
sub door::dohtem { 'dohtem' }
warn bar->SUPER::dohtem;
__END__
Can't locate object method "dohtem" via package "bar::SUPER" at - line 8.

When gv_fetchmethod_pvn_flags looks up a package it changes SUPER to
__PACKAGE__ . "::SUPER" first.  Then gv_fetchmeth_pvn uses HvNAME on
the package and strips off the ::SUPER suffix if any, before doing
isa lookup.

The problem with using __PACKAGE__ (actually HvNAME) is that it might
not be possible to find the current stash under that name.  HvENAME
should be used instead.

The above example happens to work if @ISA is changed to ‘our @ISA’,
but that is because of an @ISA bug.
Make SUPER::method respect method changes in moved pkg

->SUPER::method calls inside the Foo package cache the method for
reuse inside the stash Foo::SUPER.

Before the call, @Foo::SUPER::ISA is set to "Foo", so that those
caches will be invalidated properly.  (@ISA has the magic to make that
work.)  The actual value in @Foo::SUPER::ISA unused.

Now we have two types of package names.  If you alias the Foo package
and then clobber the original entry:

    *Bar:: = *Foo::;
    undef *Foo::;

__PACKAGE__ and HvNAME will return Foo still, but HvENAME (the effec-
tive name) will return Bar, because that is where the package is to be
found.

As of the previous commit, the package used for ISA is based on the
effective name, Bar::SUPER in this case.

But @Bar::SUPER::ISA is still set to Foo.  So even if we make changes
to methods inherited by what is now the Bar package, a previous method
cached in *Bar::SUPER::method will be reused.

BEGIN {
    *Bar:: = *Foo::;
    undef *Foo::;
}
package Bar;
@ISA = 'Baz';
*Baz::m = sub { "method 1" };
anthying->SUPER::m;
undef *Baz::m;
*Baz::m = sub { "method 2" };
warn anything->SUPER::m;
__END__
method 1 at - line 11.
[perl #114888] Localise PL_comppad_name in cv_clone

In 9ef8d56 I made closures share their pad name lists, and not just
the names themselves, for speed (no need to SvREFCNT_inc each name and
copy the list).

To make that work, I had to set PL_comppad_name in cv_clone, before
the pad_new call.  But I failed to move the PL_comppad_name localisa-
tion from pad_new to cv_clone.

So cv_clone would merrily clobber the previous value of
PL_comppad_name *before* localising it.

This only manifested itself in source filters.  Most of the time,
pp_anoncode is called at run time when either no code is being com-
piled (PL_comppad_name is only used at compile time) or inside a
BEGIN block which itself localises PL_comppad_name.  But inside a
Filter::Util::Call source filter there was no buffer like that to
protect it.

This meant that pad name creation (my $x) would create the name in the
PL_comppad_name belonging to the last-cloned sub.  A subsequent name
lookup ($x) would look in the correct place, as it uses the moral
equivalent of PadlistNAMES(CvPADLIST(PL_compcv)), not PL_comppad_name.
So it would not find it, resulting in a global variable or a stricture
violation.