| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes RT #111842. Example:
"x" =~ /\A(?>(?:(?:)A|B|C?x))\z/
Should match, but didn't due to allowing NOTHING to start a sequence.
See comment in patch for details.
This also changes a test to no longer be TODO, and improves the test
name to explain its purpose.
|
|
|
|
|
| |
These functions should be used in preference to the old ones which can
read beyond the end of the input string.
|
| |
|
|
|
|
|
| |
These functions were replaced long ago, apparently in 5.8, but I didn't
verify that for sure.
|
| |
|
|
|
|
|
| |
This both avoids cluttering the flow of manpage with auxiliary data, and
saves the user from having to extract the script from within the pod file.
|
|
|
|
|
|
| |
Installing the Perl 5 to-do list as a manpage isn't that useful to anyone, as
it's a snapshot that becomes increasingly out of date. Much better to point
anyone interested in contributing direct to git HEAD, to view the current list.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
charnames.t sometimes fails on a test that is expecting a file to be
non-existent. However, other tests in it briefly create a file by that
name. When two instances of the .t are run in parallel, as happens in
some smokes, it could be that the file exists at the time it is expected
not to. The result is a non-reproducible failure. Anyway, that is my
theory. And so this commit changes to use a filename that is used just
by the test for what happens when a file is non-existent, and hence
doesn't ever exist even transiently.
|
|
|
|
| |
See https://github.com/CPAN-API/metacpan-web/issues/485
|
| |
|
|
|
|
|
|
|
|
|
| |
A magic value (such as a tainted string) may not have POK set, so call
SvPV() to find out if there's something in ERRSV to report.
Possibly this should be using SvPV_nomg(), but this is the first
request for magic in this code. Maybe the code above should be
calling SvGETMAGIC() before checking SvROK().
|
| |
|
| |
|
|
|
|
|
|
|
| |
2f137bbd018b assumed that $name is always defined, but it isn't
always, and when it's not the resulting undefined value warning
could corrupt test output and even make TODO tests trigger failure
with "unexpected output at test 0."
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cleans up and simplifies and extends how the trie
logic interacts with the new node types. This change ultimately
makes the EXACTFU, EXACTFU_SS, EXACTFU_NO_TRIE (renamed to
EXACTFU_TRICKYFOLD) work properly with the trie engine regardless
of whether the string is utf8 or latin1.
This patch depends on the following:
EXACT => utf8 or "binary" text
EXACTFU => either pre-folded utf8, or latin1 that has to be folded as though it was utf8
EXACTFU_SS => special case of EXACTFU to handle \xDF/ss (affects latin1 treatment)
EXACTFU_TRICKYFOLD => special case of EXACTFU to handle tricky non-latin1 fold rules
EXACTF => "old style fold logic" untriable nodetype
EXACTFA => (currently) untriable nodetype
EXACTFL => (currently) untriable nodetype
See the comments in regcomp.sym for these fold types.
This patch involves a number of distinct, but related parts. Starting
from compilation:
* Simplify how we detect a triable sequence given the new nodetypes,
this also probably fixed some "bugs" in how we detected certain
sequences, like /||foo|bar/.
* Simplify how we read EXACTFU nodes under utf8 by removing the now
redundant folding logic (EXACTFU nodes under utf8 are prefolded).
Also extend this logic to handle latin1 patterns properly (in
conjunction with other changes)
* Part of the problems associated with EXACTFU_SS and EXACTFU_TRICKYFOLD
have to do with how the trie logic interacts with the minlen logic.
This change handles both by pessimising the minlen when encounting
these nodetypes. One observation is that the minlen logic is basically
broken, and works only because it conflates bytes and codepoints in
such a way that we more or less always get a value small enough that things work out
anyway. Fixing that is properly is the job of another patch.
* Part of the problem of doing folding under unicode rules is that
there are a lot of foldings possible, some with strange rules. This
means that the bitmap logic does not work correctly in all cases,
as we currently do not have any way to populate it properly.
So this patch disables the bitmap entirely when folding is involved
until that is fixed.
The end result of this is: we can TRIE/AHOCORASICK any sequence of
EXACT, or EXACTFU (ish) nodes, regardless of utf8 or not, but we disable
the bitmap when folding.
A note for follow up relating to this patch is that the way EXACTFU_XXX
nodes are currently dealt with we wont build the "maximal" trie because
of their presence, instead creating a "jumptrie" consisting of either a
leading EXACTFU node followed by a EXACTFU_XXX node, or vice versa. We
should eventually address that.
|
|
|
|
|
|
|
| |
The old output would show only the line number as diagnostics
but not the test number, nor the test name, which often contains
very useful information. This patch makes sure this is visible in
the diagnostics output of test failures.
|
|
|
|
|
|
|
|
|
|
|
| |
This provides enough rope for those who want to hang themselves, and
also for those who know how to use the rope without hanging them-
selves. :-)
Since this is not generally a reliable thing to be doing, a warning is emitted whenever :lvalue is turned on or off on a defined subroutine.
But attributes.pm will flip the flag anyway. :lvalue in a sub declar-
ation still refuses to modify a defined Perl sub, as before.
|
| |
|
|
|
|
|
|
| |
This commit looks for the passed-in charset, and overrides it only if it
is /d and the pattern requires /u. Previously the passed-in value was
ignored.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an off-by-one error caused by my failing to realize that things
had to be done differently at the 255/256 boundary depending on whether
U+00FF matched or did not match the property.
Two properties were affected, [:upper:] and [:punct:]. The bug was that
all code points above the first one > 255 that legitimately matches the
property will match whether or not they should. In the case of
[:upper:], this meant that effectively anything from 256..infinity
matched. For [:punct:], it was anything above U+037D.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it would leave the file handle open if it was (equal to) stdin,
on the assumption that this must have been because no script name was
supplied on the interpreter command line, so the interpreter was defaulting
to reading the script from standard input.
However, if the program has closed STDIN, then the next file handle opened
(for any reason) will have file descriptor 0. So in this situation, the
handle that require opened to read the module would be mistaken for the above
situation and left open. Effectively, this leaked a file handle.
This is now fixed, by explicitly tracking from parser creation time whether
it should keep the file handle open, and only setting this flag when
defaulting to reading the main program from standard input. This resolves
RT #37033.
|
|
|
|
|
| |
Test the error message generated when -x can't find a "#!perl" line.
Test that this error message still appears when -x is used with -e.
|
|
|
|
|
|
| |
Verify that -p actually runs the code in the program body.
Verify that -n doesn't implicitly print out the contents of $_.
For both, verify that an END block runs after the implicit loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't assign to two lexical variables, $Is_VMS and $Is_Win32, only to use
them immediately for the same purpose - to skip the entire test.
In turn, there's no need to conditionally set $quote to a value suitable for
VMS or Win32, when neither OS ever runs the test.
The code has been this way since the file was added by commit
742218b34f58f961 in Nov 2006. Hence I don't think that the vestigial $quote
logic corresponds to pre-commit version that did run on these platforms.
Instead I infer that it has come from t/op/exec.t, used as a template for
running sub-scripts in a portable fashion.
|
|
|
|
|
|
| |
Reading $$ in a tainted expression was tainting the internal sv_setiv()
on $$. Since the value being set came directly from getpid(), it's
always safe, so override the tainting there. Fixes [perl #109688].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a table was being allocated for OP_TRANS(|R), in a
PVOP arrangement, as soon as the op was built. However, it wasn't
used immediately, and for UTF8-flagged ops it would be thrown away,
replaced by an SV-based translation table in a SVOP or PADOP arrangement.
This mutation of the op structure occurred in pmtrans(), some time after
original op building. If an error occurred before pmtrans(), requiring
the op to be freed, op_clear() would be misled by the UTF8 flags into
treating the PV as an SV or pad index, causing crashes in the latter
case [perl #102858]. op_clear() was implicitly assuming that pmtrans()
had been performed, due to lacking any explicit indication of the op's
state of construction.
Now, the PV table is allocated by pmtrans(), when it's actually going to
populate it. The PV doesn't get allocated at all for UTF8-flagged ops.
Prior to pmtrans(), the op_pv/op_sv/op_padix field is all bits zero,
so there's no problem with freeing the op.
|
|
|
|
|
|
|
|
|
| |
See https://rt.perl.org/rt3/Ticket/Display.html?id=108776
"no feature" now resets to the default feature set. To disable all
features (which is likely to be a pretty special-purpose request, since
it presumably won't match any named set of semantics) you can now
write "no feature ':all'"
|
| |
|
|
|
|
|
|
|
| |
The Windows shell cmd.exe does not know about single quotes. Double
quotes are the only thing available here. This patch selects the kind
of quote to use based on the operating system and constructs
the pipeline accordingly.
|
|
|
|
|
|
|
|
|
| |
t/porting/pending-author.t attempts to avoid the problem of C<make test>
passing 100%, but the subsequent git commit causing F<t/porting/authors.t>
to fail, because it uses a "new" e-mail address.
This test is only run if one is building inside a git checkout, B<and> one
has made local changes. Otherwise it's skipped.
|
|
|
|
|
|
|
|
|
| |
Commit 3ea0c581844689ab didn't go far enough in pruning the input.
When Porting/checkAUTHORS.pl is invoked with --tap it uses
parse_commits_from_stdin_authors() instead of parse_commits_from_stdin(),
which only looks for lines matching /^Author:/
This reduces runtime by a further 8%.
|
|
|
|
|
|
|
|
|
|
|
|
| |
With filenames varying between only one and five characters in
length, it was fairly easy to get two files differing only in
case ('A' and 'a', for example). Which on non-case-sensitive file
systems could generate a warning at unlink time because it would
unlink 'a' and then check for the existence of 'a' and get true
because 'A' was still there and indistinguishable from 'a'.
So just use longer filenames to make the possibility of collision
vanishingly small.
|
|
|
|
|
| |
Historically Pod::Functions has failed to get updated when functions are
added. This should solve that.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pod::Functions is now generated from pod/perlfunc.pod by
ext/Pod-Functions/Functions_pm.PL
If it can't parse pod/perlfunc.pod, it will abort, which will cause the
build to break. It's really not possible for it to carry on, hence aborting
is the only option. However, innocent-seeming changes to documentation
shouldn't break the build, and we expect everyone to run (at least)
the porting tests, hence this test, to catch such problems before it's too
late. To avoid duplicating the parsing logic, we make Functions_pm.PL take
a --tap option, to test that all is well.
|
|
|
|
|
|
| |
This makes the order more consistent with test_harness, and moves the
"interesting" tests earlier. "interesting", in that these are more likely
to spot unexpected problems with the tested changes.
|
|
|
|
|
|
| |
Under locale rules, this commit quotes all non-ASCII Latin1 characters
in UTF-8 encoded strings. This provides consistency with this function
and other functions, such as lc().
|
|
|
|
|
|
|
|
|
|
| |
As described in the pod changes in this commit, this changes quotemeta()
to consistenly quote non-ASCII characters when used under
unicode_strings. The behavior is changed for these and UTF-8 encoded
strings to more closely align with Unicode's recommendations.
The end result is that we *could* at some future point start using other
characters as metacharacters than the 12 we do now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under POSIX threads the getpid() and getppid() functions return the
same values across multiple threads, i.e. threads don't have their own
PID's. This is not the case under the obsolete LinuxThreads where each
thread has a different PID, so getpid() and getppid() will return
different values across threads.
Ever since the first perl 5.0 we've returned POSIX-consistent
semantics for $$, until v5.14.0-251-g0e21945 when the getpid() cache
was removed. In 5.8.1 Rafael added further explicit POSIX emulation in
perl-5.8.0-133-g4d76a34 [1] by explicitly caching getppid(), so that
multiple threads would always return the same value.
I don't think all this effort to emulate POSIX sematics is worth it. I
think $$ and getppid() are OS-level functions that should always
return the same as their C equivalents. I shouldn't have to use a
module like Linux::Pid to get the OS version of the return values.
This is pretty much a complete non-issue in practice these days,
LinuxThreads was a Linux 2.4 thread implementation that nobody
maintains anymore[2], all modern Linux distros use NPTL threads which
don't suffer from this discrepancy. Debian GNU/kFreeBSD does use
LinuxThreads in the 6.0 release, but they too will be moving away from
it in future releases, and really, nobody uses Debian GNU/kFreeBSD
anyway.
This caching makes it unnecessarily tedious to fork an embedded Perl
interpreter. When someone that constructs an embedded perl interpreter
and forks their application, the fork(2) system call isn't going to
run Perl_pp_fork(), and thus the return value of $$ and getppid()
doesn't reflect the current process. See [3] for a bug in uWSGI
related to this, and Perl::AfterFork on the CPAN for XS code that you
need to run after forking a PerlInterpreter unbeknownst to perl.
We've already been failing the tests in t/op/getpid.t on these Linux
systems that nobody apparently uses, the Debian GNU/kFreeBSD users did
notice and filed #96270, this patch fixes that failure by changing the
tests to test for different behavior under LinuxThreads, I've tested
that this works on my Debian GNU/kFreeBSD 6.0.4 virtual machine.
If this change is found to be unacceptable (i.e. we want to continue
to emulate POSIX thread semantics for the sake of LinuxThreads) we
also need to revert v5.14.0-251-g0e21945, because currently we're only
emulating POSIX semantics for getppid(), not getpid(). But I don't
think we should do that, both v5.14.0-251-g0e21945 and this commit are
awesome.
This commit includes a change to embedvar.h made by "make
regen_headers".
1. http://www.nntp.perl.org/group/perl.perl5.porters/2002/08/msg64603.html
2. http://pauillac.inria.fr/~xleroy/linuxthreads/
3. http://projects.unbit.it/uwsgi/ticket/85
|
|
|
|
|
|
|
|
| |
This new test grants full access on a test file to group and other.
Since I'm a member of my own group and everyone is someone, I of
course have full access to the file, but the test expects it to be
unreadable. If there is a hierarchy in Unix file permissions, it
clearly doesn't work the same way as the VMS one.
|
|
|
|
|
|
|
|
|
|
| |
Commit b6c46382308166d54090e3d8e385710664693ac0 introduced a bug when
an inverted bracketed character class consists solely of a Unicode
property, that property wasn't getting inverted outside the Latin1
range.
This was due to an optimization that should have been disabled for this
case.
|
|
|
|
|
|
| |
Same for [[:upper:]] and \p{Upper}. These were matching instead all of
[[:alpha:]] or \p{Alpha}. What /\p{Lower}/i and /\p{Upper}/i match instead
is \p{Cased}, and so that is what these should match.
|