| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Instead of lengthening the struct, we can reuse SvCUR, which is cur-
rently unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These are only used for storing a string and an IV.
Making them into full-blown SVt_PVFMs is overkill.
FmLINES was only being used on these three scalars. So make it use
the SvIVX field. struct xpvfm no longer needs an xfm_lines member,
because SVt_PVFMs no longer use it.
This also causes a TODO test in taint.t to start passing, but I do
not fully understand why. But at least that’s progress. :-)
|
| |
|
|
|
| |
Win32CORE is already ithreads aware, but was still making
Perl_get_context calls. This fixes that. Smaller machine code is the result.
|
| |
|
|
|
|
|
|
|
| |
The fact that the call checker is stored in magic is an implementation
detail. cv_undef does not free magic, so the call checker lives on.
If we were to move the parameter prototype into magic internally, we
would not want undef to stop clearing it. To me, the current situa-
tion with call checkers is similar.
|
| |
|
|
|
| |
Things like /[s]/ or /[s]/i can be optimized as if they did not have the
brackets, /s/ or /s/i.
|
| | |
|
| |
|
|
| |
Previously only those matching qr/GVf_IMPORTED/ were exposed.
|
| |
|
|
|
|
| |
Previously most were exposed as constants, but often B was not taught about
flags added to cv.h. Determining the flags by parsing cv.h also permits the
removal of various version-specific logic from the Makefile.PL
|
| |
|
|
| |
Previously only a subset were exposed as constants.
|
| |
|
|
|
|
| |
It doesn't actually matter which order the files are scanned for constants,
but it's neater and slightly clearer where to add new files if there is an
obvious order.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This warning was being generated inappropriately during some internal
operations, such as parsing a program; spotted by Tom Christiansen.
The solution is to move the check for this situation out of the common
code, and into the code where just \p{} and \P{} are handled.
As mentioned in the commit's perldelta, there remains a bug
[perl #114148], where no warning gets generated when it should
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In restore_magic(), which is called after any magic processing, all of
the public OK flags have been shifted into the private OK flags. Thus
the lack of an appropriate public OK flags was used to trigger both get
magic and required conversions. This scheme did not cover ROK, however,
so all properly written code had to make sure mg_get was called the right
number of times anyway. Meanwhile the private OK flags gained a second
purpose of marking converted but non-authoritative values (e.g. the IV
conversion of an NV), and the inadequate flag shift mechanic broke this
in some cases.
This patch removes the shift mechanic for magic flags, thus exposing (and
fixing) some improper usage of magic SVs in which mg_get() was not called
correctly. It also has the side effect of making magic get functions
specifically set their SVs to undef if that is desired, as the new behavior
of empty get functions is to leave the value unchanged. This is a feature,
as now get magic that does not modify its value, e.g. tainting, does not
have to be special cased.
The changes to cpan/ here are only temporary, for development only, to
keep blead working until upstream applies them (or something like them).
Thanks to Rik and Father C for review input.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in perl 5.000, ck_grep would call ck_sort (which was still the
case until 354dd559d99 just recently) and the latter would traverse
its way through the op_next pointers to find an op that tried to
escape the block, setting its op_next pointer to null. Then ck_grep
would traverse op_next pointers itself to find the place where ck_sort
stopped. That caused problems for grep which were fixed in 748a93069b
(perl 5.001). It was fixed by setting op_next to 0 on the first op,
so that the loop in ck_grep would not do anything. But that loop was
left there. This commit removes it.
There are also a couple of things I missed when disentangling
ck_grep and ck_sort in commit /354dd559d9. I accidentally put
if (o->op_flags & OPf_STACKED) inside if (o->op_flags & OPf_STACKED).
And the OPf_SPECIAL flag was only being set for sort’s use, so ck_grep
doesn’t need to copy that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the peephole optimiser encounters a __SUB__, it looks to see
whether the current sub is clonable. If it is not, it inlines the
__SUB__ as a const op.
This works most of the time. A forward declaration will cause the sub
definition to reuse the existing stub. When that happens, the sub
visible during compilation in PL_compcv is not the sub that the
op tree will finally be attached to. But the peephole optimiser
is called after that, with PL_compcv set to the other CV (what
was a stub).
ck_sort was calling the peephole optimiser on the sort block ahead of
time. So this caused __SUB__ to point to the wrong subroutine.
By removing the CALL_PEEP call from ck_sort and adding logic to the
peephole optimiser itself to traverse the sort block (it is not in the
usual op_next chain), this bug is eliminated.
I modified the DEFER macro to work as a single statement. You don’t
want to know how much time I spent debugging the bus errors that were
occurring because if(foo) DEFER; didn’t do what I though.
It turns out that grepstart and mapstart, which also use ck_sort,
had their blocks go through the peephole optimiser twice, because
grepwhile already has special-casing in the peephole optimiser.
This also has the side-effect of making map and grep slightly more
efficient, in that they no longer execute a scope op (which is just
pp_null). By temporarily disconnecting the subtree before running the
optimiser, ck_sort was hiding a possible optimisation (skipping the
scope op).
|
| |
|
|
|
| |
--lipods warns, and I don't think it is needed in this test,
so I have removed it
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 39c012bc2fc2f1cf wasn’t enough. If a subroutine has a proto-
type beginning with * then its name is treated as a sub call, even
when followed by a package name:
{package Foo}
sub Foo {}
foo Foo; # Foo->foo
{package Bar}
sub bar (*) {}
bar Bar; # bar(Bar)
This was not applying to subs looked up via rv2cv hooks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ perl5.17.2 -Mblib -e 'sub foo{}; foo $bar; use Lexical::Sub baz => sub{}; baz $bar'
Can't call method "baz" on an undefined value at -e line 1.
$ perl5.17.2 -Mblib -e 'sub foo{}; foo bar; use Lexical::Sub baz => sub{}; baz bar'
Can't locate object method "baz" via package "bar" (perhaps you forgot to load "bar"?) at -e line 1.
So if you use Lexical::Sub, your sub doesn’t get to participate in
determining whether ‘foo $bar’ or ‘foo bar’ is a method call.
This is because Lexical::Sub uses an rv2cv hook to intercept sub
lookup. And toke.c:S_intuit_method thinks there cannot be a CV with-
out a GV (which was the case when it was first written).
Commit f7461760 introduced this rv2cv hooking for bareword lookup, but
failed to update S_intuit_method accordingly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an op is allocated, PL_compcv is checked to see whether it can
hold an op slab if it does not hold one already. If PL_compcv is not
usable, for whatever reason, it falls back to malloc.
Since the new slab allocator was added in commit 8be227a, newFOROP has
been assuming, probably correctly, that its listop which it needs to
enlarge to a loopop was allocated by slab.
Since newFOROP is an API function, we should err on the safe side and
check first whether the op is slab-allocated, falling back to realloc
if it is not.
To trigger this potential bug, one has to set things up such that
there is a usable pad available, but no usable PL_compcv. I said
‘probably correctly’ above because this situation is highly unlikely
and probably indicative of bugs elsewhere. (But we should still err
on the side of safety.)
|
| |
|
|
|
|
|
|
|
|
| |
These macros have never worked outside the Latin1 range, so this extends
them to work.
There are no tests I could find for things in handy.h, except that many
of them are called all over the place during the normal course of
events. This commit adds a new file for such testing, containing for
now only with a few tests for the isBLANK's
|
| |
|
|
|
|
|
|
|
| |
The XS API allows hash entries to be created with null values. perl
itself uses these internally, too.
Though they should rarely be seen by Perl code, Perl ops should still
be able to handle them without crashing (by croaking). I fixed helem
and hslice in 5.16 (commit 746f6409), but missed localised deletions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In trying to fix bug #112780, I made in-memory handle duplication tem-
porarily hide the underlying scalar so it wouldn’t be set to the empty
string (commit 49b69fb3a).
I used PerlIO_sv_dup in j rather than PerlIOScalar_arg. The for-
mer is usually what is called anyway. There is only one branch of
PerlIOScalar_arg that doesn’t call PerlIO_sv_dup. I don’t remember
what I was thinking back then, but I think I thought that branch
was there for paranoia. But actually, it is used for "&=", so this
started failing:
open FILE, '>', \my $content or die "Couldn't open scalar filehandle";
open my $fh, ">&=FILE" or die "Couldn't open: $!";
print $fh "Foo-Bar\n";
close $fh;
close FILE;
print $content;
This commit fixes the bug in the smallest way possible, which means
switching from PerlIO_sv_dup to PerlIOScalar_arg in PerlIOScalar_arg,
which, in turn, entails fiddling with RVs.
|
| |
|
|
| |
Thanks to Jesse Luehrs and Father Chrysostomos for testing advice.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Update the docs and add perldelta entries summarising the changes and
fixes related to (?{}) and (??{}) accumulated over the 120 or so commits
in this branch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In /.........(??{ some_string_value; }).../flags
and /(?flags).(??{ some_string_value; }).../,
use flags when compiling the inner /some_string_value/ pattern.
Achieve this by storing the compile-time modifier flags in the
(apparently) unused 'flags' field of the EVAL node in the (??{})
case.
|
| | |
|
| |
|
|
|
| |
these were used as part of the old "use re 'eval'" security
mechanism used by the now-eliminated PL_reginterp_cnt
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perl's internal function for compiling regexes that knows about code
blocks, Perl_re_op_compile, isn't part of the engine API. However, the
way that regcomp.c is dual-lifed as ext/re/re_comp.c with debugging
compiled in, means that Perl_re_op_compile is also compiled as
my_re_op_compile. These days days the mechanism to choose whether to call
the main functions or the debugging my_* functions when 'use re debug' is
in scope, is the re engine API jump table. Ergo, to ensure that
my_re_op_compile gets called appropriately, this method needs adding to
the jump table.
So, I've added it, but documented as 'for perl internal use only, set to
null in your engine'.
I've also updated current_re_engine() to always return a pointer to a jump
table, even if we're using the internal engine (formerly it returned
null). This then allows us to use the simple condition (eng->op_comp)
to determine whether the current engine supports code blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this commit, qr// with a literal (compile-time) code block
will Do the Right Thing as regards closures and the scope of lexical vars;
in particular, the following now creates three regexes that match 1, 2
and 3:
for my $i (0..2) {
push @r, qr/^(??{$i})$/;
}
"1" =~ $r[1]; # matches
Previously, $i would be evaluated as undef in all 3 patterns.
This is achieved by wrapping the compilation of the pattern within a
new anonymous CV, which is then attached to the pattern. At run-time
pp_qr() clones the CV as well as copying the REGEXP; and when the code
block is executed, it does so using the pad of the cloned CV.
Which makes everything come out all right in the wash.
The CV is stored in a new field of the REGEXP, called qr_anoncv.
Note that run-time qr//s are still not fixed, e.g. qr/$foo(?{...})/;
nor is it yet fixed where the qr// is embedded within another pattern:
continuing with the code example from above,
my $i = 99;
"1" =~ $r[1]; # bare qr: matches: correct!
"X99" =~ /X$r[1]/; # embedded qr: matches: whoops, it's still
seeing the wrong $i
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make Perl_re_compile() a thin wrapper around a new function,
Perl_re_op_compile(). This function can take either a string pattern or a
list of ops. Then make pmruntime() pass a list of ops directly to it, rather
concatenating all the consts into a single string and passing the const to
Perl_re_compile(). For now, Perl_re_op_compile just does the same: if its
passed an op tree rather than an SV, then it just concats the consts.
So this is is just the next step towards eventually allowing the regex
engine to use the ops directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I ran into a bit of a problem when building perl-5.16.0.
'make test' showed a segfault in ext/XS-APItest/t/clone-with-stack.t.
It seems to be caused by accessing already freed memory, it
segfaults because I have MALLOC_PERTUBE_ set, thus glibc fills
freed memory with some value.
Digging deeper, it seems like perl_clone() does not fix
the cx's blk_oldcop element when doing context cloning, thus
blk_oldcop still points to PL_compiling in the old interp--the
calling scope for the BEGIN block being the compilation of the
code surrounding it--and the POPBLOCK done in leavesub will copy
the data from the old interp to PL_curcop.
After fixing this, it still crashed because interp_dup->Iop was
zero after the runops_standard() call (which is probably
correct as the end of the BEGIN block was reached). So I
also added an if statement that checks the pointer.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This was mentioned in ticket #113060.
This commit also adds another stashoff test.
The diff looks a bit complicated, because it stops ->file and
->stashpv from being XS aliases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was brought up in ticket #78742.
The stashlen method has never been in a stable release, and no longer
exists, as of d4d03940c, since it is dependent on a define that
d4d03940c removed.
So this commit removes stashlen from B.xs and adds stashoff in its
place, since this is what B::C needs.
It also adds a few basic tests for the stash and stashpv methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, a pointer to the cop’s stash was stored in
cop->cop_stash under non-threaded perls, and the name and name length
were stored in cop->cop_stashpv and cop->cop_stashlen under ithreads.
Consequently, eval "__PACKAGE__" would end up returning the
wrong package name under threads if the current package had been
assigned over.
This commit changes the way cops store their stash under threads. Now
it is an offset (cop->cop_stashoff) into the new PL_stashpad array
(just a mallocked block), which holds pointers to all stashes that
have code compiled in them.
I didn’t use the lexical pads, because CopSTASH(cop) won’t work unless
PL_curpad is holding the right pad. And things start to get very
hairy in pp_caller, since the correct pad isn’t anywhere easily
accessible on the context stack (oldcomppad actually referring to the
current comppad). The approach I’ve followed uses far less code, too.
In addition to fixing the bug, this also saves memory. Instead of
allocating a separate PV for every single statement (to hold the stash
name), now all lines of code in a package can share the same stashpad
slot. So, on a 32-bit OS X, that’s 16 bytes less memory per COP for
short package names. Since stashoff is the same size as stashpv,
there is no difference there. Each package now needs just 4 bytes in
the stashpad for storing a pointer.
For speed’s sake PL_stashpadix stores the index of the last-used
stashpad offset. So only when switching packages is there a linear
search through the stashpad.
|
| | |
|
