| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise pod like this:
The second situation is caused by an eval accessing a lexical subroutine
that has gone out of scope, for example,
sub f {
my sub a {...}
sub { eval '\&a' }
}
f()->();
is turned into this:
The second situation is caused by an eval accessing a variable that has
gone out of scope, for example,
sub f {
my $a;
sub { eval '$a' }
}
f()->();
instead of this:
The second situation is caused by an eval accessing a variable that has
gone out of scope, for example,
sub f {
my $a;
sub { eval '$a' }
}
f()->();
I don’t know how to test this without literally copying and pasting
parts of diagnostics.pm into diagnostics.t. But I have tested it man-
ually and it works.
|
| |
|
|
|
|
|
|
| |
This variable only held the package name. __PACKAGE__ is faster,
as it allows constant folding.
diagnostics.pm just happens to be older than __PACKAGE__, which was
introduced as recently as 1997 (68dc074516).
|
| | |
|
| |
|
|
|
| |
This keeps any trailing data in the file from showing up as part
of the last warning's description.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Support multi-line "=item ..." expressions per the POD spec.
This also allows warnings with white-space differences to match.
|
| |
|
|
|
|
|
| |
This reverts commit c369a25dcc5e5c5b627a50d1c4b73c2be0b926b9.
I have just reverted the only other change to diagnostics.pm
since 5.17.2.
|
| |
|
|
|
|
|
|
| |
This reverts commit 019070c31184a4deb57cb85f7e597a789c6c5b54.
I misunderstood $^S, and thought I could simplify the code. Contrary
to what perlvar says, $^S is undefined not only during compilation of
an eval or module, but also during compilation of the main program.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are deprecating literal left braces in regular expressions. The 5.16
delta announced that this is coming.
This commit causes a warning to be raised when a literal "{" is
encountered. However, it does not do this if the left brace is at the
beginning of a construct. Such a brace does not cause problems for us
for our future use of it for other purposes, as, for example in things
like \b{w}, and there were a large number of core tests that failed
without this condition.
I didn't mention this exception in the diagnostic. We may choose to
forbid it everywhere, and we certainly want to discourage its use
everywhere. But this commit gets the essential components in early in
5.17, and we can tighten it up later if we decide to.
|
| |
|
|
|
| |
It only helps with very long strings. It actually slows things down
slightly when used on short strings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pods are installed into privlib. Before Perl 5.005, privlib didn't contain
the version number in it, so 5.004 and 5.003 (etc) both installed to the same
directory. perldiag.pod differed in not-quite compatible ways, so hacks were
put in to (a) also install it in privlib with the version number in the
filename (b) to hard link it to archlib, which always did contain the version
number.
5.005 changed privlib to contain the version number, solving the underlying
problem (strictly commit bfb7748a896459cc, described here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-07/msg00136.html )
Commit a841533b5cf319b3 (Oct 2009) removed the first installation hack,
Commit e8ea61279d90dbe9 (Jul 1998) removed the second.
Hence the code to search in the "hacked" locations is no longer needed,
and in the interests of clarity, should go.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I hope you agree this backtrace does not look very good:
$ ./perl -Ilib -Mdiagnostics -e '
sub foo { bar () }
sub bar { baz() }
sub baz {
die "Attempt to reload foo aborted.\nCompilation failed in require"} foo
'
Attempt to reload foo aborted (#1)
(F) You tried to load a file with use or require that failed to
compile once already. Perl will not try to compile this file again
unless you delete its entry from %INC. See "require" in perlfunc and
"%INC" in perlvar.
Compilation failed in require at -e line 1 (#2)
(F) Perl could not compile a file specified in a require statement.
Perl uses this generic message when none of the errors that it
encountered were severe enough to halt compilation immediately.
Uncaught exception from user code:
Attempt to reload foo aborted.
Compilation failed in require at -e line 1.
main::baz() called at -e line 1
main::bar() called at -e line 1
main::foo() called at -e line 1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the ‘Compilation failed’ messages are actually multiline mes-
sages, like "Attempt to reload foo aborted.\nCompilation failed in
require at ...".
perldiag has separate entries for each line of the message, so it
makes sense to have it look up each line. It can’t split it into
lines by default, but must check for a possible description first, as
sometimes syntax errors quote code with line breaks in it.
I had to rip out the nasty file-wide lexical $_, as I couldn’t local-
ise it, and I undid d923656e4 in the process.
|
| |
|
|
|
| |
As of commit 58618f23, it has been setting %CarpInternal, so
setting $CarpLevel is unnecessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently a user-defined error message is printed out like this:
-----
Uncaught exception from user code:
panick: at -e line 1.
at -e line 1
main::baz() called at -e line 1
main::bar() called at -e line 1
main::foo() called at -e line 1
-----
Errors generated from perl itself are printed like this:
-----
panic: at -e line 1 (#1)
(P) An internal error.
Uncaught exception from user code:
panic: at -e line 1.
at -e line 1
main::baz() called at -e line 1
main::bar() called at -e line 1
main::foo() called at -e line 1
-----
By using Carp::confess(), we end up with a screwy backtrace. Some-
times it just ends up repeating the error and line number:
-----
panic: at -e line 1 (#1)
(P) An internal error.
Uncaught exception from user code:
panic: at -e line 1.
at -e line 1
-----
Uncaught exception from user code:
panick at -e line 1.
at -e line 1
-----
This commit cleans these up to print like this:
-----
Uncaught exception from user code:
panick: at -e line 1.
main::baz() called at -e line 1
main::bar() called at -e line 1
main::foo() called at -e line 1
-----
panic: at -e line 1 (#1)
(P) An internal error.
Uncaught exception from user code:
panic: at -e line 1.
main::baz() called at -e line 1
main::bar() called at -e line 1
main::foo() called at -e line 1
-----
panic: at -e line 1 (#1)
(P) An internal error.
Uncaught exception from user code:
panic: at -e line 1.
-----
Uncaught exception from user code:
panick at -e line 1.
-----
You might ask: Why not remove the ‘uncaught exception’ message alto-
gether after an error description. It’s because the error description
is a diagnostic, which only prints once for each error or warning
encountered. So you could have eval { die } somewhere else in the
code, which causes a description to be printed. And later you have a
die() that exits the program, but nothing gets printed.
In other words, the description of the message does not replace
the error.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Update spacing
Don't break S<20 questions> across lines, update test to be accurate
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have entries in perldiag like this:
=item Code point 0x%X is not Unicode, may not be portable
=item Code point 0x%X is not Unicode, no properties match it; all inverse properties do
(W utf8) You had a code point above the Unicode maximum of U+10FFFF.
...
diagnostics.pm needs to know that the description applies to the first
=item, as well as to the second.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The number of L<foo/bar> links in perldiag has grown over time, and
diagnostics.pm has never been updated to render them nicely, resulting
in output like this:
Lexing code attempted to stuff non-Latin-1 character into Latin-1 input at
lib/diagnostics.t line 36 (#3)
(F) An extension is attempting to insert text into the current parse
(using lex_stuff_pvn_flags|perlapi/lex_stuff_pvn_flags or similar), but
tried to insert a character that couldn't be part of the current input.
This is an inherent pitfall of the stuffing mechanism, and one of the
reasons to avoid it. Where it is necessary to stuff, stuffing only
plain ASCII is recommended.
I’ve implemented some rudimentary L<> parsing, which should suffice
for perldiag. I think using a real POD processor would be overkill.
|
| |
|
|
| |
./perl -Ilib Porting/cmpVERSION.pl -xd . v5.13.8
|
| |
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81890]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81890 >
Signed-off-by: Abigail <abigail@abigail.be>
|
| |
|
|
|
| |
ExtUtils::MakeMaker removed MacOS support in 6.25, merged to blead in December
2004, so this code is vestigial, and a small runtime penalty.
|
| |
|
|
|
|
| |
(or flip)' warning
(and bump version of diagnostics.pm)
|
| |
|
|
|
|
|
|
|
| |
The message ‘localtime(...) too large’ is not documented in perldiag.
The attached patch adds it. I know it’s technically ‘%s(%.0f) too
large’, but it’s easier for users to find it under ‘localtime’ and
‘gmtime’. I also had to modify diagnostics.pm to support %.0f, and I
added a test, but I used a hack with STDERR that would make debugging
very difficult to anyone else adding tests.
|
| | |
|
| |
|
| |
p4raw-id: //depot/perl@30601
|
| |
|
| |
p4raw-id: //depot/perl@30492
|
| |
|
|
|
| |
This fixes bug #41717.
p4raw-id: //depot/perl@30491
|
| |
|
|
|
|
| |
stop C<use diagnostics; warn "\n"> outputing lots of 'uninit'
warnings.
p4raw-id: //depot/perl@28231
|
| |
|
|
|
|
| |
From: "Fergal Daly" <fergal@esatclear.ie>
Message-ID: <875029960605171059y286fe449nd39d6830ef2b229a@mail.gmail.com>
p4raw-id: //depot/perl@28224
|
| |
|
| |
p4raw-id: //depot/perl@26804
|
| |
|
|
|
|
| |
From: "Piotr Fusik" <pfusik@op.pl>
Message-ID: <001401c595bd$dccb5d80$0bd34dd5@piec>
p4raw-id: //depot/perl@25261
|
| |
|
|
|
|
| |
From: "Steve Peters via RT" <perlbug-followup@perl.org>
Message-ID: <rt-3.0.11-30227-98375.1.28465791111211@perl.org>
p4raw-id: //depot/perl@23422
|
| |
|
|
|
| |
Message-ID: <20040803233309.GA239@dyn.fergaldaly.com>
p4raw-id: //depot/perl@23191
|
| |
|
| |
p4raw-id: //depot/perl@23019
|
| |
|
|
|
| |
Message-ID: <20040525092937.GA2332@efn.org>
p4raw-id: //depot/perl@22848
|
| |
|
| |
p4raw-id: //depot/perl@22018
|
