| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
When --libpods was removed, this broke backward compatiblility with
existing uses. This change adds back the option, but warns that
--libpods is no longer supported.
|
| | |
| |
| |
| | |
actually write the files out using utf-8. This is a fix for RT #111446.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We are repeating standard prototypes but we haven't been making
them compatible with the standard versions when compiling under
C++. Now we do.
|
| | |
| |
| |
| |
| |
| |
| | |
Whether we really need to be rolling our own prototypes for malloc
and free in this day and age is unclear, but since we do, we need
to keep them in the unmangled C namespace rather than in C++'s
std:: namespace.
|
| | |
| |
| |
| | |
C++ doesn't speak K & R.
|
| | |
| |
| |
| |
| | |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| | |
| |
| |
| | |
C++ needs an explicit type on the handler.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The core is not using it any more. Every CPAN module that increments
it also does newXS, which triggers mro_method_changed_in, which is
sufficient; so nothing will break.
So, to keep those modules compiling, PL_amagic_generation is now an
alias to PL_na outside the core.
|
| | |
| |
| |
| |
| | |
6379d4a9a (between 5.15.9 and 5.16.0) broke B::COP::stashflags which was added
in 5.15.4.
|
| | |
| |
| |
| |
| |
| | |
The previous commit modified Pod::Functions by modifying perlfunc.pod,
but we have things set up in such a way that cmp_version.t won’t
see it.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
How ironic! Overloading is called ‘A’ magic internally all over the
place, because of the letter used as its magic type. But now it does
not even use that magic.
I left a comment in mg_vtable.pl, so that future maintainers will have
some clue as to what AMAGIC means.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that mro_method_changed_in (triggered by the
‘*{$package . "::()"} = \&nil;’ assignment) causes overloadedness to
be checked the next time a overloaded operation occurs, it is not nec-
essary to trigger %OVERLOAD’s magic explicitly.
This also means that PL_amagic_generation is not incremented any more.
Unfortunately, we cannot eliminate it, as there are XS modules that
expect to increment it themselves to mark their caches as stale.
|
