| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
B was still using some PERL_VERSION checks
in multiple places whereas it's part of core.
This commit removes this dead code and bump B::VERSION.
For archeology we can still use git if we want to know
what it looks like in an older version.
|
| |
|
| |
|
|
|
|
|
|
|
| |
$Carp::MaxArgNums is supposed to be the number of arguments to display.
For a long time, Carp has instead shown $Carp::MaxArgNums + 1 arguments.
Correct the behavior by making it match the documentation. Also update
tests to make what's being tested more obvious.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Follow wording from Camel book, 4th ed., p. 120, per suggestion by
Ludovic E. R. Tolhurst-Cleaver. Add Ludovic E. R. Tolhurst-Cleaver
to AUTHORS.
For: RT #125802
|
|
|
|
|
|
|
|
|
| |
In Hash::Util, the functions lock_hashref_recurse and
unlock_hashref_recurse were omitted from the @EXPORT_OK array,
the synopsis in the POD, and the test for exported functions in
t/Util.t. This commit adds those functions in all three places.
For: RT #125730
|
| |
|
|
|
|
|
|
| |
Fixing minor encoding inconsistencies found by scan_mojibake utility
(https://metacpan.org/pod/distribution/Test-Mojibake/bin/scan_mojibake)
This patch is touching only comments/POD/__DATA__
|
| |
|
| |
|
|
|
|
|
|
| |
Add Chase Whitener to Perl AUTHORS.
For: RT #125313
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The 'output_warning' param is actually used, and 'items' is not a function
argument but a local variable.
|
| |
|
|
|
|
|
|
| |
Extracted from patch submitted by Lajos Veres in RT #123693.
Add Lajos Veres to Perl AUTHORS.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When someone suggests a new warning on p5p it always often up being
argued about on the basis that it'll break existing code, and that we
shouldn't add warnings for possibly legitimate code just because it's
unusual or odd.
As I pointed out in a discussion about RT #121025 (see [1]) we only keep
having this discussion because until now we've had no facility to add
new warnings outside of the default set that'll be retroactively enabled
for everything that does 'use warnings'. This patch introduces such a
facility.
As a proof of concept I'm adding a warning for something that was added
as a warning in the past, but pulled out because it was deemed too
controversial at the time: warning about the use of grep in void
context.
That warning was added back in v5.10.0-218-g74295f0 but quickly pulled
out in v5.10.0-230-gf5df478. See [2] for the discussion about it at the
time.
Now if you do:
use warnings;
grep /42/, (1,2);
You'll get no warnings as before, but if you do:
use warnings qw(extra); # Or its sole subcategory: void_unusual
grep /42/, (1,2);
You'll get a warning about "Unusual use of grep in void context". To
turn off this warning once you've turned it on it's *not* sufficient to
do:
no warnings;
You need to do:
no warnings qw(pedantic);
Or:
no warnings qw(everything);
I'm willing to change that, but first we should ask ourselves whether
this should continue to remain a symmetric operation:
{use,no} warnings ['all'];
There's more elaboration on how this works in the changes I'm making to
the perldelta and the warnings documentation. But briefly this should be
100% backwards compatible, but allow us to have our cake and eat it too
in the future by adding new warnings without imposing them on existing
code written against older perl versions (unless that code explicitly
requested to get new warnings as they upgrade perl).
The patch to the warnings.pm documentation lays out a backwards
compatibility policy for warnings, we promise that we'll continue the
status quo with the "all" category, but for other categories (including
future additions) we'll make such promises on a per-category basis.
TODO: I wanted to come up with some more general facility for being able
to add these new warnings without altering the behavior of the -w and -W
switches. I.e. now we'll emit this, as intended:
$ ./perl -Ilib -w -e 'grep /42/, (1,2)'
$ ./perl -Ilib -W -e 'grep /42/, (1,2)'
$ ./perl -Ilib -e 'use warnings; grep /42/, (1,2)'
$ ./perl -Ilib -e 'use warnings "extra"; grep /42/, (1,2)'
Unusual use of grep in void context at -e line 1.
I.e. we don't want -w and -W to mean "use warnings 'everything'", it
should continue to mean "use warnings 'all'". But due to how they're
implemented I couldn't find an easy way to generalize this. Right now
I'm just hardcoding an exception to the new warning category I've added
outside "all" for these warnings.
That should be followed-up with a more general solution, but for now if
we only have a few of these catogeries we should be fine.
This patch incorporates work from Andreas Guðmundsson
<andreasg@nasarde.org> who picked up an earlier version of mine and
figured out the change being made to mg.c here. That change removes an
optimization in the ${^WARNING_BITS} magic which might make things a tad
slower.
1. https://rt.perl.org/Ticket/Display.html?id=121025#txn-1276663
2. http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131922.html
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Minor POD-formatting changes.
Add Johann 'Myrkraverk' Oskarsson to Perl AUTHORS.
For: RT #123230
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On certain machines, the file system timestamps are in local time, so
assigning a timestamp based on a time() call is prone to jump timezones to
UTC.
Anthony Heading is now a Perl 5 author.
For: RT #122609
|
| |
|
|
|
|
|
|
| |
"ps" on Android has different syntaxes depending on the tool used.
It can be toolbox or busybox. Bypass the "ps" tests and enable
the /proc/$$/cmdline one.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Add Dmitri Tikhonov to Perl 5 AUTHORS.
Increment IPC/Open3.pm $VERSION.
For: RT #119843, originally reported by A.N.
|
|
|
|
|
|
| |
Add Michael Bunk to Perl AUTHORS.
For: https://rt.perl.org/Ticket/Display.html?id=122120
|
| |
|
|
|
|
|
|
| |
Changed "<> should be quotes" to "<> at require-statement should be
quotes". This way, when someone writes "require <Module>", it is way
easier to find the specific command that caused this.
|
|
|
|
|
|
| |
Discovered during POD unit tests on release of 5.70 to CPAN.
Also correct AUTHORS and checkAUTHORS.PL email to toddr@cpan.org.
Bump Exporter $VERSION to 5.71.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Storable documentation recommends using dclone shortcut in
STORABLE_freeze hook: "Unless you know better, serializing hook should
always say:
sub STORABLE_freeze {
my ($self, $cloning) = @_;
return if $cloning; # Regular default serialization
....
}
in order to keep reasonable dclone() semantics."
However, this causes a memory leak which is easy to observe with the
following small script:
=== storable-leak.plx ===
use Storable qw( dclone );
package Foo {
sub new { return bless {}, __PACKAGE__ }
sub STORABLE_freeze {
my( $self, $cloning ) = @_;
# Switch to regular default serialization results in memory leak
return if $cloning;
return 'Foo';
}
}
my $d = Foo->new();
while(1)
{
dclone( $d );
}
===
The leak is caused by missing cleanup of empty array value returned by
the hook. I've attached a simple patch for Storable-2.45 which fixes
this issue.
Reported in [perl #121928]
Amended to include version bump and Storable changelog entry.
|
| |
|
| |
|