| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #130621
In ckDEAD(), don't check the value of PL_curcop->cop_warnings unless
PL_curcop is non-null.
In the ticket above, the reason that PL_curcop is null is the less
than optimal way that evals free their optree: ideally the optree should
be attached to the eval CV and freed when the CV is; instead a separate
SAVEFREEOP() is done. But that fix is for another time; regardless,
ckDEAD() should have a PL_curcop != NULL guard anyway like isLEXWARN_on()
etc already do.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
See the explanation in the test added and in the RT ticket.
The solution is to make the warn macros check that PL_curcop
is non-null.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang has taken it upon itself to warn when an equality is wrapped in
double parentheses, e.g.
((foo == bar))
Which is a bit dumb, as any code along the lines of
#define isBAR (foo == BAR)
if (isBAR) {}
will trigger the warning.
This commit shuts clang up by putting in a harmless cast:
#define isBAR cBOOL(foo == BAR)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts & amends my v5.21.7-151-gea5519d and Karl Williamson's
v5.21.7-183-g2f3cbe1, the latter was only need because of the
former.
I've also taken the opportunity to fix the long-standing trivial bug
with misaligned code in warnings.{pm,h}. That was easier to commit along
with this than to split it up from the other generated changes.
Why revert this? See the "use warnings 'absolutely-all-almost';" thread
on perl5-porters for the latest summary:
http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225066.html
Basically as I explained in v5.21.7-151-gea5519d the current design of
the API makes it too contentious to freely add new warnings, but there's
no consensus on how to solve that. I.e. whether we should just add them
to "all", or do this change, or several other possible things outlined
in that thread and elsewhere.
Since the deadline for contentious changes for v5.22 is already past us
I'm backing this out for now.
|
| | |
|
| |
|
|
| |
This is a step in the process of adding that subpragma.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
This category will be used in future commits for warnings that are
entirely because of locale issues.
|
| |
|
|
|
| |
Also correct the description of lvref magic. When it was first added,
it was for list assignments only, but that soon changed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement RT #121025 and add a "redundant" warning category that
currently only warns about redundant arguments to printf. Now similarly
to how we already warned about missing printf arguments:
$ ./miniperl -Ilib -we 'printf "%s\n", qw()'
Missing argument in printf at -e line 1.
We'll now warn about redundant printf arguments:
$ ./miniperl -Ilib -we 'printf "%s\n", qw(x y)'
Redundant argument in printf at -e line 1.
x
The motivation for this is that I recently fixed an insidious
long-standing 6 year old bug in a codebase I maintain that came down to
an issue that would have been detected by this warning.
Things to note about this patch:
* It found a some long-standing redundant printf arguments in our own
ExtUtils::MakeMaker code which I submitted fixes to in
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/84 and
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/86,
those fixes were merged into blead in v5.19.8-265-gb33b7ab
* This warning correctly handles format parameter indexes (e.g. "%1$s")
for some value of correctly. See the comment in t/op/sprintf2.t for
an extensive discussion of how I've handled that.
* We do the correct thing in my opinion when a pattern has redundant
arguments *and* an invalid printf format. E.g. for the pattern "%A%s"
with one argument we'll just warn about an invalid format as before,
but with two arguments we'll warn about the invalid format *and* the
redundant argument.
This helps to disambiguate cases where the user just meant to write a
literal "%SOMETHING" v.s. cases where he though "%S" might be a valid
printf format.
* I originally wrote this while the 5.19 series was under way, but Dave
Mitchell has noted that a warning like this should go into blead
after 5.20 is released:
"[...] I think it should go into blead just after 5.20 is
released, rather than now; I think it'd going to kick up a lot of
dust and we'll want to give CPAN module owners maximum lead time
to fix up their code. For example, if its generating warnings in
cpan/ code in blead, then we need those module authors to fix
their code, produce stable new releases, pull them back into
blead, and let them bed in before we start pushing out 5.20 RC
candidates"
I agree, but we could have our cake and eat it too if "use warnings"
didn't turn this on but an explicit "use warnings qw(redundant)" did.
Then in 5.22 we could make "use warnings" also import the "redundant"
category, and in the meantime you could turn this on
explicitly.
There isn't an existing feature for adding that kind of warning in
the core. And my attempts at doing so failed, see commentary in RT
#121025.
The warning needed to be added to a few places in sv.c because the "",
"%s" and "%-p" patterns all bypass the normal printf handling for
optimization purposes. The new warning works correctly on all of
them. See the tests in t/op/sprintf2.t.
It's worth mentioning that both Debian Clang 3.3-16 and GCC 4.8.2-12
warn about this in C code under -Wall:
$ cat redundant.c
#include <stdio.h>
int main(void) {
printf("%d\n", 123, 345);
return 0;
}
$ clang -Wall -o redundant redundant.c
redundant.c:4:25: warning: data argument not used by format string [-Wformat-extra-args]
printf("%d\n", 123, 345);
~~~~~~ ^
1 warning generated.
$ gcc -Wall -o redundant redundant.c
redundant.c: In function ‘main’:
redundant.c:4:5: warning: too many arguments for format [-Wformat-extra-args]
printf("%d\n", 123, 345);
^
So I'm not the first person to think that this might be generally
useful.
There are also other internal functions that could benefit from
missing/redundant warnings, e.g. pack. Neither of these things currently
warn, but should:
$ perl -wE 'say pack "AA", qw(x y z)'
xy
$ perl -wE 'say pack "AAAA", qw(x y z)'
xyz
I'll file a bug for that, and might take a stab at implementing it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Ever since the warning for missing printf arguments was added in
v5.11.2-116-g7baa469 the "missing" warning category has been defined in
terms of the "uninitialized" category, so you couldn't turn it on/off
independently of that.
As discussed in RT #121025 I'm hacking on adding a new "reduntant"
category for too many printf arguments. So add the long-missing
"missing" category in preparation for that for consistency.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Declarative syntax to unwrap argument list into lexical variables.
"sub foo ($a,$b) {...}" checks number of arguments and puts the
arguments into lexical variables. Signatures are not equivalent to the
existing idiom of "sub foo { my($a,$b) = @_; ... }". Signatures are only
available by enabling a non-default feature, and generate warnings about
being experimental. The syntactic clash with prototypes is managed by
disabling the short prototype syntax when signatures are enabled.
|
| | |
|
| |
|
|
|
| |
We need a better name for the experimental category, but I have not
thought of one, even after sleeping on it.
|
| |
|
|
|
| |
These note that warnings categories should be independent in the calls
to ckWARN() and packWARN() type macros.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check for the nul char in pathnames and string arguments to
syscalls, return undef and set errno to ENOENT.
Added to the io warnings category syscalls.
Strings with embedded \0 chars were prev. ignored in the syscall but
kept in perl. The hidden payloads in these invalid string args may cause
unnoticed security problems, as they are hard to detect, ignored by
the syscalls but kept around in perl PVs.
Allow an ending \0 though, as several modules add a \0 to
such strings without adjusting the length.
This is based on a change originally by Reini Urban, but pretty much
all of the code has been replaced.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This on-by-default warning will be raised upon use of the
soon-to-be-delivered regex sets feature. The syntax used is currently
invalid, so no feature activation is necessary.
The purpose of this warning is to make sure that any user is properly
notified that this feature is experimental and subject to change
|
| | |
|
| |
|
|
|
|
|
| |
I reindented the tree in perllexwarn because I was simply copying and
pasting the output from:
perl regen/warnings.pl tree
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
All users of close_and_rename() were printing out the appropriate "ex: set ro:"
string to the file handle immediately before closing it. So move that into
the common function and rename it to reflect what it now does. [Except
overload.pl, which should have been, given that it calls read_only_top()]
Print a newline above the "ex: set ro:" line. This removes many newlines from
the regen scripts, but does add newlines to a couple of generated files.
|
| |
|
|
|
|
|
|
|
| |
Previously all the scripts in regen/ had code to generate header comments
(buffer-read-only, "do not edit this file", and optionally regeneration
script, regeneration data, copyright years and filename).
This change results in some minor reformatting of header blocks, and
standardises the copyright line as "Larry Wall and others".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
category to a new 'illegalproto' subcategory.
Two warnings can be emitted when parsing a prototype -
Illegal character in prototype for %s : %s
Prototype after '%c' for %s : %s
The first one is emitted when any invalid character is found, the latter
when further prototype-type stuff is found after a slurpy entry (i.e. valid
character but in such a place as to be a no-op, and therefore likely a bug).
These warnings are distinct from those emitted when a sub is overwritten by
one with a different prototype, and when calls are made to subroutines with
prototypes - those are in the pre-existing sub-category 'prototype'.
Since modules such as signatures.pm and Web::Simple only need to disable
the warnings during parsing, I chose to add a new category containing only
these. Moving these warnings into the 'prototype' sub-category would have
forced authors to disable more warnings than they intended, and the entire
raison d'etre of this patch is to allow the specific warnings involved to
be disabled.
In order to maintain compatibility with existing code, the new location
needed to be a sub-category of 'syntax' - this means that
no warnings 'syntax';
will continue to work as expected - even in cases like Web::Simple where all
subcategories extant prior to this patch are re-enabled (this is another
reason why a move into the 'protoype' category would not achieve the desired
goal).
The category name 'illegalproto' was chosen because the most common warning
to encounter is the "Illegal character" one, and therefore 'illegalproto'
while minorly inaccurate by ignoring the (relatively recent and unknown)
second warning is an easy name to spot on an initial skim of perllexwarn
and will behave as expected by also disabling the case of an unusual prototype
that happens to look like a normal one.
This patch updates pod/perllexwarn.pod, perldiag.pod and perl5113delta.pod
to document the new category, toke.c and warnings.pl to create and implement
the new category, and a new test t/op/protowarn.t that verifies the new
behaviour in a number of cases. It also includes the files generated by
regen.pl that are found in the repo - notably warnings.h and lib/warnings.pm.
|
| |
|
|
|
|
| |
The core never uses WARN3() or WARN4(), and rarely uses WARN2(), so the
previous code, effectively an unwrapped loop, wasn't a speed up. Functionally
equivalent smaller code fits better into CPU caches.
|
| |
|
|
|
|
| |
the limit of representation in NVs, using a new warnings category
"imprecision".
p4raw-id: //depot/perl@32990
|
| |
|
| |
p4raw-id: //depot/perl@31386
|
| |
|
| |
p4raw-id: //depot/perl@30365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ 28144]
In Perl_Gv_AMupdate(), there's no need to call sv_unmagic() if we know
the magic isn't there.
[ 28145]
Simplify the non-printable name error reporting code in Perl_allocmy().
[ 28176]
Subject: [PATCH] Speed up utf8.c a bit
Date: Thu, 11 May 2006 22:41:01 -0500
Message-ID: <20060512034101.GA10709@petdance.com>
[ 28178]
The upgrade/croak order in Perl_sv_utf8_encode() seemed utterly
backwards. It now checks for readonly *first*.
[ 28179]
Subject: [PATCH] Proper use of static funcs in toke.c and pp_sys.c
From: andy@petdance.com (Andy Lester)
Date: Tue, 9 May 2006 12:27:30 -0500
Message-ID: <20060509172730.GA5272@petdance.com>
[ 28180]
Subject: [PATCH] upgrade bytes_to_uni
From: andy@petdance.com (Andy Lester)
Date: Fri, 12 May 2006 00:21:23 -0500
Message-ID: <20060512052123.GA21648@petdance.com>
[ 28194]
Subject: [PATCH] S_reguni should return its length
From: andy@petdance.com (Andy Lester)
Date: Sun, 14 May 2006 09:46:32 -0500
Message-ID: <20060514144632.GA20935@petdance.com>
ooops, and also something in blead that wasn't meant to sneak in:
Change PERL_WARNHOOK_FATAL to &PL_sv_placeholder, rather than some
evil cast relative to NULL.
p4raw-link: @28194 on //depot/perl: 71207a3462fa4c2b33c5608a4362ac40e975ecdb
p4raw-link: @28180 on //depot/perl: 64844641e1be28fdf8b7bba9436537339624f40b
p4raw-link: @28179 on //depot/perl: 931e0695c454f4c18f68d30775151862650cc4d8
p4raw-link: @28178 on //depot/perl: a5f5288a1ce96404c41043e92557b8c1a5ad9e30
p4raw-link: @28176 on //depot/perl: 3ebfea2846d81f58e86dfcb7f9e09300e5dfcd17
p4raw-link: @28145 on //depot/perl: d1544d85966c2f41014a6f408fd81b36501caa7c
p4raw-link: @28144 on //depot/perl: 14899595d82ccba509ac7743655764129ed32177
p4raw-id: //depot/perl@29980
|
| |
|
|
|
|
| |
on by default, without having to play games with the
warning bits. Add a test for -t.
p4raw-id: //depot/perl@29717
|
| |
|
|
|
| |
to warnings.pl
p4raw-id: //depot/perl@28666
|
| |
|
| |
p4raw-id: //depot/perl@28663
|
| |
|
|
|
| |
Message-ID: <44D2E203.5050201@iki.fi>
p4raw-id: //depot/perl@28662
|
| |
|
| |
p4raw-id: //depot/perl@28148
|
| |
|
|
|
|
|
| |
directly (shared) malloc()ed buffer holding the warnings bitmask.
This avoids bugs/crashes when the interpreter that created an optree
is freed but the optree remains in use by other interpreters.
p4raw-id: //depot/perl@27779
|
| |
|
|
|
|
| |
simple replace of Nullsv with NULL turns out to be a bad idea.
* Technically undefined behaviour, I believe.
p4raw-id: //depot/perl@27078
|
| |
|
|
|
| |
Rafael.
p4raw-id: //depot/perl@27067
|
| |
|
| |
p4raw-id: //depot/perl@25050
|
| |
|
|
|
| |
("Suggest parentheses to clarify precedence")
p4raw-id: //depot/perl@24938
|
| |
|
|
|
| |
Message-ID: <20050517231701.GA1394@mccoy.peters.homeunix.org>
p4raw-id: //depot/perl@24509
|
