| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Prior to this patch, this module assumed every =item was for a
diagnostic. Now it keeps track, and so a given diagnostic can have a
list within it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the regex handler to properly match in many
instances a \N{named sequence} in a bracketed character class.
A named sequence is one which consists of a string of multiple
characters but given one name. Unicode has hundreds of them, like LATIN
CAPITAL LETTER A WITH MACRON AND GRAVE. These are encoded by Unicode
when there is some user community that thinks of the conglomeration as a
single unit, but there was no prior standard that had it so, and it is
possible to encode it in Unicode using other means, typically a sequence
of a base character followed by some combining marks. (If there had not
been such a prior standard, 8859-1, things like LATIN CAPITAL LETTER A
WITH GRAVE would have been put into Unicode this way too.) If they did
not do it this way, they would run out of availble code points much
sooner.
Not having these as single characters adds a burden to the programmer
having to deal with them. Hiding this detail as much as possible makes
it easier to program. This commit hides this in one more place than
previously.
It takes advantage of the infrastructure added some releases ago dealing
with the fact that the match of some single characters
case-insensitively can be 2 or even 3 characters.
"ss" =~ /[ß]/i;
is the most prominent example.
We earlier discovered that /[^ß]/ leads to unexpected behavior, and
using one of these sequences as an endpoint in a range is also unclear
as to what is meant. This commit leaves existing behavior for those
cases. That behavior is to use just the first code point in the
sequence for regular [...], and to generate a fatal syntax error for
(?[...]).
|
| |
|
|
|
|
| |
The original version of this patch, introduced in
v5.19.2-389-g8140a7a, warned confusingly when incrementing strings
like "123abc". This version includes the fix patch from [perl
|
| |
|
|
| |
This is in preparation for it to be called from another place
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This failed as in it was producing:
Argument "123abc" treated as 0 in increment (++) at -e line 1.
when the user incremented that value (which is a lie).
This reverts commits 8140a7a801e37d147db0e5a8d89551d9d77666e0 and
2cd5095e471e1d84dc9e0b79900ebfd66aabc909.
I expect to revert this commit, and add fixes, after 5.20 is released.
Conflicts:
pod/perldiag.pod
|
| |
|
|
|
| |
This adds a test so that both =item lines of an adjacent pair get
tested.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is testing that things work for two adjacent =item lines in
perldiag.pod that share the same description. However a future commit
will change perldiag.pod so that one of the specific adjacent lines
previously used here will be removed. Therefore, choose a different set
of adjacent lines that aren't scheduled to be changed.
This adds a comment in perldiag that the newly chosen adjacent lines are
thus used in diagnostics.t
|
| |
|
|
|
| |
This keeps any trailing data in the file from showing up as part
of the last warning's description.
|
| | |
|
| |
|
|
| |
They are sensitive to changes in perldiag.pod
|
| | |
|
| |
|
|
|
|
| |
* Support regcomp.c ckWARN and vWARN macros
* Update pod/perldiag.pod for fixes discovered with new checks
* Allow t/porting/diag.t to match printfs with flags more liberally
|
| |
|
|
|
|
| |
Support multi-line "=item ..." expressions per the POD spec.
This also allows warnings with white-space differences to match.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I thought I had run it, hmm.
|
| |
|
|
|
|
| |
Express the one-liner with qq to interpolating \n to a newline character at
execution time, instead of q quoting a literal newline character. Passing
a literal newline character is not portable to all platforms.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
so that runperl is available
|
| | |
|
| |
|
|
|
|
| |
Update spacing
Don't break S<20 questions> across lines, update test to be accurate
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Commit 96090e4 changed a diagnostic message, but didn't update
lib/diagnostics.t
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Big MacPerl Testing Patch No. 2
Big MacPerl Testing Patch No. 3
p4raw-id: //depot/perl@16942
p4raw-integrated: from //depot/macperl@16937 'copy in'
lib/Devel/SelfStubber.pm lib/Devel/SelfStubber.t
lib/File/DosGlob.t lib/File/Path.t lib/File/Spec/t/Spec.t
lib/File/Temp.pm lib/FindBin.t lib/Tie/File/t/09_gen_rs.t
lib/lib.t t/comp/use.t utils/dprofpp.PL utils/splain.PL
(@16123..) t/lib/MakeMaker/Test/Utils.pm (@16230..)
lib/diagnostics.t (@16646..) lib/ExtUtils/t/00setup_dummy.t
lib/ExtUtils/t/Command.t (@16730..) lib/lib_pm.PL (@16926..)
lib/ExtUtils/MM_MacOS.pm lib/Test/Harness/Straps.pm
lib/Test/Harness/t/callback.t
lib/Test/Harness/t/strap-analyze.t
lib/Test/Harness/t/test-harness.t (@16929..)
p4raw-integrated: from //depot/macperl@16926 'merge in' lib/English.t
(@16123..) ext/DynaLoader/DynaLoader_pm.PL (@16868..)
|
| |
|
| |
p4raw-id: //depot/perl@16490
|
| |
|
|
|
| |
Message-Id: <20010822200300.0D1638253@ool-18b93024.dyn.optonline.net>
p4raw-id: //depot/perl@11726
|
|
|
No doubt I made some mistakes like missed some files or
misnamed some files. The naming rules were more or less:
(1) if the module is from CPAN, follows its ways, be it
t/*.t or test.pl.
(2) otherwise if there are multiple tests for a module
put them in a t/
(3) otherwise if there's only one test put it in Module.t
(4) helper files go to module/ (locale, strict, warnings)
(5) use longer filenames now that we can (but e.g. the
compat-0.6.t and the Text::Balanced test files still
were renamed to be more civil against the 8.3 people)
installperl was updated appropriately not to install the
*.t files or the help files from under lib.
TODO: some helper files still remain under t/ that could
follow their 'masters'. UPDATE: On second thoughts, why
should they. They can continue to live under t/lib, and
in fact the locale/strict/warnings helpers that were moved
could be moved back. This way the amount of non-installable
stuff under lib/ stays smaller.
p4raw-id: //depot/perl@10676
|
