| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
The strict pragma only effects the current file or block scope, but we
never mention that in the docs. Thanks KES for reporting this.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In half the calls to to_utf8_case(), the code point being looked up is
known. It is thrown away because the API doesn't pass it, and then
recalculated first thing in to_utf8_case.
Fix this by making a new static function which adds the code point to
the parameter list, and change all calls to use this, leaving the
existing to_utf8_case() as just a wrapper for the new function.
|
|
|
|
|
|
|
|
|
|
|
|
| |
With ${^ENCODING} set, it did.
Partly reverts:
commit aa8f6cef961dc2009604f7464c66106421c3ae81
Author: Rafael Garcia-Suarez <rgs@consttype.org>
Date: Wed Jun 17 13:18:59 2015 +0200
Microoptimize some matches in utf8_heavy.pl
|
|
|
|
|
|
| |
...not the hyphenated form
commit message by rjbs
|
|
|
|
|
|
| |
Patch submitted by Shlomi Fish.
For: RT #126735
|
|
|
|
|
|
|
|
| |
use cmp_ok() instesd of ok() where apppriate and similar things to
get better diagnostucs when things fail (e.g. display what the bad value
was, rather than just letting you know it was bad).
Also, use diag() rather than 'print STDERR "# .....\n";'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The number of iterations to do on various tests was set at 3 or 10
in the first incarnation of the test file 13 years ago, and hasn't
changed since. In the meantime, CPUs have gotten faster. So bump the
iteration count to 100. This makes no appreciable difference to total wall
time for the test file on my newish x86_64 platform, but will hopefully
make tests less likely to be running within the noise of a single 100Hz
clock tick.
In particular, the NetBSD smokes were quite frequently failing tests 127
and 128, due to the CPU taken to do an empty loop being greater than that
for a full loop, thus leading to negative apparent execution time. This
was likely to be due to the first taking "1" clock tick and the second
taking "0" ticks. Although this is less likely to happen now that the
iterations has been increased, this commit also adds a check to
Benchmark.pm for a negative apparent execution time, and if detected,
prints a "too few iterations" warning and resets it to zero.
|
|
|
|
|
| |
A couple of places do basically the same set of summing various times()
fields within a Benchmark object, so make it into a private method.
|
|
|
|
|
|
|
|
|
| |
2 tests in a particular block of code are consistently failing on a newbsd
smoker.
Make a copy of that block of code but with the result object and
chart object generated separately, then diag dump both if any of the
tests in that new block fail, so we can see better what's going wrong.
|
|
|
|
|
|
|
|
| |
Two tests fail a lot of smokes; those tests assert that two
code variants when one is faster than the other should show a percentage
difference > 0. Then the differences are slight, the percentage may round
down to zero and the test will fail. Reduce the likelihood of this my
making one code variant a lot slower than the other
|
|
|
|
|
|
|
| |
locale handling doesn't work without POSIX module being able to load, so
doesn't work on minitest. Prior to this patch, the code checked for
only one case of locale handling to skip when there was no POSIX, but
there was a 2nd case if failed to detect.
|
| |
|
| |
|
|
|
|
|
|
|
| |
These tests were using individually defined heuristics to decide whether
to do locale testing or not. However t/loc_tools.pl provides functions
that are more reliable and complete for determining this than the
hand-rolled ones in these tests.
|
|
|
|
|
|
|
| |
These may not actually exist in the wild, but it is better to be
general.
This also adds an XXX comment about future possibilities.
|
|
|
|
|
| |
Patch received from Ruud H.G. van Tol <rvtol@isolution.nl>.
Committer added ++$VERSION and Porting/checkAUTHORS.pl change.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Through an oversight, the text that was supposed to be printed as the
name for a test was just getting output as a 1 or 0.
|
|
|
|
|
| |
This function's capabilities has expanded beyond its original use, but
the descriptive comments weren't until now.
|
|
|
|
|
|
| |
7e6d00f88633 added the warnif() function and changed most uses of
warnings:enabled() to use warnif(), including this one. Revert
just that part.
|
|
|
|
|
|
|
| |
regen/warnings.pl's $VERSION was at 1.04 despite it being modified
each time warnings.pm is modified.
So make them use the same version number.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit made it clear that the N argument to EXTEND()
is supposed to be signed, in particular SSize_t, and now typically
triggers compiler warnings where this isn't the case.
This commit fixes the various places in core that passed the wrong sort of
N to EXTEND(). The fixes are in three broad categories.
First, where sensible, I've changed the relevant var to be SSize_t.
Second, where its expected that N could never be large enough to wrap,
I've just added an assert and a cast.
Finally, I've added extra code to detect whether the cast could
wrap/truncate, and if so set N to -1, which will trigger a panic in
stack_grow().
This also fixes
[perl #125937] 'x' operator on list causes segfault with possible
stack corruption
|
|
|
|
| |
Actually, I don’t think they have needed it for a while.
|
|
|
|
| |
It is no longer used.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This ticket was originally because the requester did not realize the
function Unicode::UCD::charscript took a code point argument instead of
a chr one. It was rejected on that basis. But discussion here
suggested it would be better to warn on bad input instead of just
returning <undef>. It turns out that all other routines in Unicode::UCD
but charscript and charblock already do warn. This commit extends that
to the two outlier returns.
|
|
|
|
|
|
|
| |
Avoids aliasing %- and @- as %FORMAT_LINES_LEFT and @FORMAT_LINES_LEFT.
I audited the rest of perlvar and English.pm for over-eager aliasing of
unrelated variables but found no other cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes perluniprops to not list the equivalent 'In' single form
method of specifying the Block property, and to discourage its use. The
reason is that this is a Perl extension, the use of which is unstable.
A future Unicode release could take over the 'In...' name for a new
purpose, and perl would follow along, breaking the code that assumed the
former meaning. Unicode does not know about this Perl extension, and
they wouldn't care if they did know.
The reason I'm doing this now is that the latest Unicode version
introduced some properties whose names begin with 'In', though no
conflicts arose. But it is clear that such conflicts could arise in the
future. So the documentation only is changed to warn people of this
potential.
perlunicode is update accordingly.
|
|
|
|
|
|
|
|
| |
Special code suppressed the expanded output of some ranges, where it
would be clear from the range itself what was meant. However, for many
output tables, that range output was changed, so the desired
information is missing. For these tables, don't suppress the expanded
output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code assumed that all locale categories were represented by
non-negative whole numbers. However, it turns out that this assumption
is wrong, as on AIX, LC_ALL is -1. This commit changes our assumption to
take into account that reality; it now assumes that all categories are
larger than a much more negative number, and now the new assumption is
tested for, and if wrong, the code dies instead of silently doing the
wrong thing.
There was also a bug where if a locale category wasn't defined on the
machine, but the corresponding #ifdef for using that category was still
set, the category was improperly assumed to exist
|
| |
|
|
|
|
|
| |
This file rolls its own TAP, and it did not have its ok() return
pass/fail.
|
|
|
|
|
|
|
|
|
| |
It turns out that the code assumes that the values for LC_CTYPE,
LC_MESSAGES, ... are small non-negative numbers, as a bit position is
reserved for each of these. It's better to make this assumption
explicit rather than getting hard-to-find failures.
(LC_ALL doesn't have to be of this form, and is in fact -1 on AIX)
|
| |
|
|
|
|
|
|
|
| |
Some of the test chose code points that did not match its assumptions as
to their classifications.
And some of the tests were extended to work on 1047 EBCDIC
|
|
|
|
|
|
|
| |
The tests for the Latin1 \xFF aren't a fair test of UTF-8 on EBCDIC
platforms, because it is generally a UTF-8 invariant character, so is
the same regardless of being in UTF-8 or not. This adds some tests
where the UTF-EBCDIC version is 2 bytes (as well as the UTF-8 version).
|
|
|
|
|
| |
These globals are already available; by using them instead of rolling
our own, it makes it easer to grep for these kinds of instances.
|
| |
|
|
|
|
|
| |
The DAge.txt property until the previous commit had to be handled
out-of-the-normal order. This is no longer required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality is rarely used, but enables someone to see what
Unicode has changed between releases X and Y, without the clutter of the
things that are added after X came out. In other words it compiles
release X using Y's rules. To use it, you must go in and edit mktables
to specify to use this; so it is intended only for a developer who wants
to look at Unicode history. One use I've done is to look at the beta
version of a new release to compare with the previous official one.
This allows me to find typos, and unintentional changes and report them
back to Unicode.
This commit significantly overhauls this feature, giving better results
than before.
|
|
|
|
|
|
| |
There were several glitches when compiling very early Unicode releases.
This commit changes things so the age property reference is stored in a
global, and doesn't have to be refound multiple times.
|
|
|
|
|
|
| |
This takes two code sections and moves them to a function each. For
one, this is in preparation for being used in a 2nd place. For the
other, call the code in existing other places.
|
|
|
|
|
|
|
| |
The Default_Ignorable_Code_Point property is applicable to unassigned
code points, so shouldn't restrict our calculated value to assigned.
(We calculate what the property would be when run on Unicode releases
that haven't defined it yet.)
|