| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reimplements $[ using PL_check hooks, custom pp func-
tions and ties.
Outside of its compile-time use, $[ is now parsed as a simple varia-
ble, so function calls like foo($[) are permitted, which was not the
case with the former implementation removed by e1dccc0. I consider
that a bug fix.
The ‘That use of $[ is unsupported’ errors are out of necessity
deferred to run-time and implemented by a tied $[.
Indices between 0 and the array base are now treated consistently, as
are indices between a negative array base and zero. That, too, is
a bug fix.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This makes it just a little bit easier for release managers
and also fixes the perennial north-hemisphere bias in the future
release date.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We already have porting tests catching this. I really don't see how this could
end up being screwed or how it'd be more likely at this point during the release
process than at any other time.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks, David!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was only ever turning it on, and not turning it off if the sv hap-
pened to have it on from its previous use.
This caused ref() (which uses sv_sethek(TARG,...)) to return a shared
scalar with the UTF8 flag on, even if it was supposed to be off.
For shared scalars, the UTF8 flag on ASCII strings does make a differ-
ence. The pv *and* the flags are used in hash lookup, for speed.
So a scalar returned by ref() with the UTF8 flag on by mistake would
not work in hash lookups. exists $classes{ref $foo} would return
false, even if there were an entry for that class.
|
| |
|
|
| |
This has been untrue since it was added in commit 6e592b3a.
|
| |
|
|
|
| |
The historical NetBSD hints need tweaking for dynamic linking flags, and
older versions of unixish.h needs tweaking to include <signal.h>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It was trying to download a test file that doesn't exist in minicpans.
|
| | |
|
| |
|
|
|
|
|
|
| |
Tiny typo, this will fix it:
[dkaarsemaker@dromedary perl]$ git diff
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
|
| | |
|
| |
|
|
| |
This adds regrepeat to no keep re-folding to the recent commits
|
| |
|
|
|
| |
A recent commit caused regexec.c to not keep calculating the folds in
one circumstance. This one adds the case in regmatch
|
| |
|
|
|
| |
The lowercase of latin-1 range code points is known to the perl core, so
for those we can short-ciruit converting to utf8 and reading in a swash
|
| |
|
|
|
|
|
|
|
|
|
| |
If you watch an execution trace of regexec /i, often you will see it
folding the same thing over and over, as it backtracks or searches
ahead. regcomp.c has now been changed to always fold UTF-8 encoded
EXACTF and EXCACTFU nodes. This allows these to not be re-folded each
time.
This commit does it just for find_by_class(). Other commits will expand
this technique for other cases.
|
| | |
|
| |
|
|
|
| |
Indent newly formed blocks, and reflow comments and code to fit in
narrower space
|
| |
|
|
|
| |
This adds flags so that if one of the input strings is known to already
have been folded, this routine can skip the (redundant) folding step.
|
| | |
|
| |
|
|
|
| |
Indent the newly formed block, and reflow comments for narrower
available space.
|
| |
|
|
|
|
| |
regcomp.c folds the string in these two nodes except in one case.
Change that case to correspond with the predominant behavior. This
enables future optimizations
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial reversion of commit
7c1b9f38fcbfdb3a9e1766e02bcb991d1a5452d9
which went unnecessarily far in fixing the problem.
After studying the situation some more, I see more clearly what was
going on. The point is that if you have only 2 characters left in the
string, but the pattern requires 3 to work, it's guaranteed to fail, so
pointless, and unnecessary work, to try. So don't being a match trial
at a position when there are fewer than the minimum number of characters
necessary. That is what the code before that commit did. However it
neglected the fact that it is possible for a single character to match
multiple ones, so there is not a 1:1 ratio. This new commit assumes the
worst possible ratio to calculate how far into a string is the furthest
a successful match could start. This is going to in most cases still
look too far, but it is much better than always going up to the final
character, as the previous patch did.
The maximum ratio is guaranteed by Unicode to be 3:1, but when the
target isn't in UTF-8, the max is 2:1, determined simply by inspection
of the defined folds. And actually, currently, the single case where it
isn't 1:1 doesn't come up here, because regcomp.c guarantees that that
match doesn't generate one of these EXACTFish nodes. However, I expect
that to change for 5.16, and so am preparing for that case by making it
2:1.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This outdents a block to the same level as the surrounding text, and
reflows the comments to take advantage of the extra space and use fewer
lines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code was always #ifdef'd out. It would have been used to convert
to a Greek final sigma from a non-final one, depending on context. The
problem is that we can't know algorithmically if a final sigma is in
order or not. I excerpt this quote, that I find persuasive, from
correspondence from Father Chrysostomos, who knows Greek:
"I cannot see how any algorithm can know to get it right.
"The letter σ (or Σ in capitals) represents the number 200 in Greek
numerals. Those are not just ancient Greek numerals, but are used on a
regular basis even in modern Greek. In many printed books ς is used in
place of ϛ, which represents the number 6. So if casefolding should
change ͵ΑΣʹ to ͵αςʹ, or if an output layer changes ͵ασʹ similarly, it
will be changing the number (from 1200 to 1006). You can’t get around
it by checking for the Greek numeral sign (ʹ), as sometimes the tonos
(΄), oxeia (´), or even the ASCII straight quote is used. And often in
lists or chapter titles a dot is used instead of numeral sign.
"Also, σ is commonly used at the ends of abbreviations. Changing ‘βλέπε
σ. 16’ (‘see page 16’) to ‘βλέπε ς. 16’ is not acceptable.
"So, no, I don’t think a programming language should be fiddling with σ
versus ς. (A word processor is another matter.)"
|
| |
|
|
|
|
|
| |
The structure of this code is that initial setup is done and then gotos
or fall-through used to join for the main logic. This commit just moves
a block, without logic changes, so that the more common case has a
fall-through instead of a goto.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Brian's comments:
if xhv_name_count == 1, HvENAME_HEK_NN returns null.
So there's no need to use that macro twice. Just check for -1
The real need to make these smaller is the fact that some precompilers
(e.g. HP-UX 10.20) cannot cope with the size these have grown to. The
precompiler has since got an option (-Hnnn) to increase the macrospace
but that option never made it to these old compilers.
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
|
| |
|
|
|
|
| |
When displaying op_next, it currently shows a null value as "DONE",
which while meaningful on a completely compiled tree, is confusing
on a partially-built tree, where multiple ops may have an op_next of null.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, whenever we dump an op tree, we first call sequence(),
which walks the tree, creating address => sequence# mappings in
PL_op_sequence. Then when individual ops or op-next fields are displayed,
the sequence is looked up.
Instead, do away with the initial walk, and just map addresses on request.
This simplifies the code.
As a deliberate side-effect, it no longer assigns a seq# of zero to
null ops. This makes it easer to work out what's going on when you
call op_dump() during a debugging session with partially constructed
op-trees. It also removes the ambiguity in "====> 0" as to whether
op_next is NULL or just points to an op_null.
|
| | |
|
| | |
|
| |
|
|
| |
Commit 7c60e434 removed the ‘match’.
|
| |
|
|
|
|
| |
Commit aa33328e8 inadvertently removed the null checks from
stashpv_hvname_match when adding UTF8 support, resulting in crashes it
List::Gen’s test suite.
|
| | |
|
| | |
|
