| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This is my quick-and-dirty script:
find dist -print0 | xargs -0 perl -pi -e 'BEGIN { %map = split " ", join "", `cat pb2rt.txt` } s/(?<!\d)\d{8}\.\d{3}(?!\d)/$& (#$map{$&})/g'
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As proposed by RJBS.
The "5.24" feature bundle (and therefore C<< use v5.24 >>) now enable
postderef and postderef_qq.
I can't find any precedent for what to do with the relevant experimental::*
warnings category when an experimental feature graduates to acceptance. I
have elected to leave the category in place, so that code doing C<< no
warnings "experimental::postderef" >> will continue to work. This means that
C<< use warnings "experimental::postderef" >> is also accepted, but has no
effect.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(...)x... is marked as a list at compile time and given a pushmark,
before the context is known. If it turns out to be called in scalar
or void context after all, then pp_repeat has to handle the mark that
has been pushed on to the markstack.
It was not handling the mark for overloading. Nor was it handling
void context correctly at all. (The stack may have an empty list, in
which case we call FETCH on a potentially tied stack item that has
nothing to do with us.)
I tested it in void context, because I plan to undo the listification
when scalar context is applied, for speed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was code in op.c:ck_rvconst (which runs when creating a derefer-
ence op, such as rv2sv, rv2av, etc.) that would check that a constant
kid holding a reference pointed to something of the right type. It
failed to take overloading into account.
The result was that these lines would fail to compile:
constant_reference_to_hash_with_coderef_overloading->();
constant_reference_to_sub_with_hashref_overloading->{key};
constant_reference_to_sub_with_arrayref_overloading->[0];
constant_reference_to_sub_with_scalarref_overloading->$*;
even though they should work.
Since the overloadedness could change any time, even checking for that
in op.c is incorrect. The only correct fix is to remove this compile-
time check. If something naughty gets through, it will be caught
at run time.
This fixes bugs #122607 and #69456.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As I noted in v5.21.1-12-g826af13 we have subtle bugs in the test suite
because you can do e.g. like($@, '') now which'll be a passing test even
when we have an error, because $@ =~ // will be true.
I'm just changing t/test.pl to not accept non-Regexp arguments, and
fixing up a bunch of test failures that resulted from that. There might
still be more of these in tests that I'm just not running, I've also
changed some of these from $str =~ /foo/ to $str eq 'foo'
(i.e. s/like/is/) in cases where that appeared to work, but it might
break some systems.
Let's just find that out via the smokers.
|
| |
|
|
|
|
|
|
|
|
|
| |
My recent commit 3d147ac29d12abdb to "speed up (non)overloaded derefs"
introduced a potential SEGV. In Perl_Gv_AMupdate(), the 'aux' variable is
set to HvAUX(hv). My patch used the value of the variable later on in the
function, but it turns out that by then, S_hsplit() may have been called,
and thus HvARRAY (and HvAUX()) may have been reallocated.
Issue first spotted by Andreas' awesome BBC service, and diagnosed by
Nicholas Clark.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit ba36554e02872e48d146177a57a9cfb154727fae.
It turns out it reinstates bugs like this:
$ perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}'
main at -e line 1.
maio at -e line 1.
maip at -e line 1.
maiq at -e line 1.
mair at -e line 1.
mais at -e line 1.
mait at -e line 1.
maiu at -e line 1.
maiv at -e line 1.
maiw at -e line 1.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit 19130678b4 stopped copy-on-write scalars from being exempt from
readonliness in ck_svconst (called for every OP_CONST). That was for
the sake of consistency.
It turns out this breaks CPAN modules, so change it back, but only for
shared hash key scalars, not other COW scalars.
This is an historical artefact left over from when copy-on-write used
the read-only flag without the scalar actually being read-only.
|
| |
|
|
|
|
|
| |
They were not read-only if the constant handler returned a shared
hash key scalar.
This was brought up in bug #109744.
|
| |
|
|
| |
including one to-do test
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
arguments"
This reverts commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b.
This is reverted in reference to [perl #113834]. Although this commit
does fix a real bug, it introduces a new one that is arguably worse.
More importantly, it is a regression from 5.16.0. We should produce a
test case that solves both bugs, then solve them both, then get that in
place. Before 5.18.0 would be nice. After 5.18.0 may have to do.
|
| |
|
|
|
|
| |
There was code to detect this, but it checked for the returned value being
the same as before, but in this case it was returning a *new* temporary
reference to the same Regexp object; so check for that too.
|
| |
|
|
|
|
|
| |
The default case for non-overloaded classes is fallback => 1, so saying
fallback => 1 on its own shouldn't enable overloading, but saying
fallback => undef on its own should (even though undef is the default
for overloaded classes).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes
package Foo;
use overload fallback => 0;
and
package Bar;
use overload '+' => \&add, fallback => 0;
behave identically when an operator other than '+' is used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
amagic_call now does its best to propagate the operator's context into
the overload callback. It's not always possible - for instance,
dereferencing and stringify/boolify/numify always have to return a
value, even if it's not used, due to the way the overload callback works
in those cases - but the majority of cases should now work. In
particular, overloading <> to handle list context properly is now
possible.
For backcompat reasons (amagic_call and friends are technically public
api functions), list context will not be propagated unless specifically
requested via the AMGf_want_list flag. If this is passed, and the
operator is called in list context, amagic_call returns an AV* holding
all of the returned values instead of an SV*. Void context always
results in amagic_call returning &PL_sv_undef.
|
| |
|
|
|
|
| |
re-apply commits done to lib/overload.t on the blead branch between
2012/03/31 and 2012/06/04, which were removed to make rebasing the
re_eval branch easier.
|
| |
|
|
|
|
|
|
| |
In this case, always pass the object to the regex compiler, which
knows how handle this.
(The diff looks more complex than it actually is: it just wraps
the whole (logical == 2) branch with an 'if (!SvAMAGIC(ret))'.)
|
| |
|
|
|
| |
some tests in lib/overload.t were temporarily removed earlier to ease
rebasing; add them back in now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When called, pp_regcomp() is presented with a list of SVs on the stack.
Previously, it would perform (amongst other things):
* overloading those SVs;
* concatenating them;
* detection of bare /$qr/;
* detection of unchanged pattern;
optionally followed by a call to the built-in or an external regexp
compiler.
Since we want to avoid premature concatenation (so that we can handle
/$runtime(?{...})/), move all these activities from pp_regcomp() into
re_op_compile().
This makes re_op_compile() a bit cumbersome, with a large arg list,
but I haven't found any way of only moving only a subset of the above.
Note that a side-effect of this is that qr-overloading now works for all
regex compilations, not just those reached via pp_regcomp(); in particular
this now invokes the qr method rather than the "" method if available:
/(??{ $overloaded_object })/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ DAPM: I just cherry-picked the tests from this commit, since my own
changes have already fixed this bug. FC's two commits:
15d9c083b08647e489d279a1059b4f14a3df187b
3e1022372a8200bc4c7354e0f588c7f71584a888
were unrolled at the start of this branch since they clashed with my own
stuff; this commit is re-adding the bits of those commits that are
still needed: i.e. just the tests.
]
In 5.8.x, this code:
use overload '""'=>sub { warn "stringify"; --$| ? "gonzo" : chr 256 };
my $obj = bless\do{my $x};
warn "$obj";
print "match\n" if chr(256) =~ $obj;
prints
stringify at - line 1.
gonzo at - line 3.
stringify at - line 1.
match
which is to be expected.
In 5.10+, the stringification happens one extra time, causing a failed match:
stringify at - line 1.
gonzo at - line 3.
stringify at - line 1.
stringify at - line 1.
This logic in pp_regcomp is faulty:
if (DO_UTF8(tmpstr)) {
assert (SvUTF8(tmpstr));
} else if (SvUTF8(tmpstr)) {
... copy under ‘use bytes’...
}
else if (SvAMAGIC(tmpstr)) {
/* make a copy to avoid extra stringifies */
tmpstr = newSVpvn_flags(t, len, SVs_TEMP | SvUTF8(tmpstr));
}
The SvAMAGIC check never happens when the UTF8 flag is on.
|
| |
|
|
|
|
|
|
| |
(bug found by code inspection)
The code in pp_regcomp to make a mortal copy of the pattern string
in the case of overload or utf8+'use bytes', missed the case of overload
with utf8. Fix this and at the same time simplify the code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Remove some repeated code in pp_regcomp"
This reverts commit 3e1022372a8200bc4c7354e0f588c7f71584a888.
Revert "regcomp.c: Use no_mg for 2nd fetch of pattern"
This reverts commit 3e0b93e82af0f1a033bcdb918b413113f1d61cf0.
`
Revert "PATCH: [perl #101940]: BBC Tk"
This reverts commit 11951bcbfcaf4c260b0da0421e72fc80b4654f17.
Revert "Fix =~ $str_overloaded (5.10 regression)"
This reverts commit 15d9c083b08647e489d279a1059b4f14a3df187b.
These four recent commits on the blead branch overlap with work on the
re_eval branch. To make rebasing re_eval easier, revert them at the
beginning of the re_eval branch. Any remaining value will be re-added
later in the re_eval branch.
|
| |
|
|
|
| |
these accumulated from a few recent commits. Removing will make rebasing
easier.
|
| |
|
|
|
|
| |
undo commits done to lib/overload.t on the blead branch
between 2012/03/31 and 2012/06/04 to make rebasing the re_eval
branch easier. These changes will be re-applied at the end of the rebase
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is in the case where we search for an overloaded operator when
passing the AMGf_assign flag (we're executing an assignment operator
like +=).
At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
not passed, we first try to look up the overload method corresponding
to the assignment operator, then the normal one if fallback is
authorized. However, if this fails, when trying later to find
overload magic with the arguments swapped (if AMGf_noright is not
passed), this procedure was not used and we looked up directly the base
operation from which the assignment operator might be derived.
As a consequence of what an operator like += might have looked
autogenerated even when fallback=>0 was passed.
This change only necessitates a minor adjustment in lib/overload.t,
where an overloaded += method wasn't corresponding semantically to the
overloaded + method of the same class, which can be seen as a
pathological case.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, there is code all over CPAN that assumes fallback is
stored under the "()" stash entry. And that code also assumes that
the overloadedness flag (the existence of the CV) is in the same spot.
So much for encapsulation.
This commit changes overloading itself to use a different key, "((",
while having it search for "()" first, and then "((" only if "()" is
not found, to preserve compatibility with encapsulation-breaking code.
So the "((" key will only be used by gv.c if there is no fallback
value specified at all.
|
| |
|
|
|
|
|
| |
While doing a PL_glob_index experiment on a branch, I almost screwed
up the stack for those cases where glob is overridden and there is
iterator overloading. The tests passed anyway, meaning we need
more tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to overload’s documentation, ‘[v]alues specified as strings
are interpreted as method names.’
But it behaves differently if the string contains a double colon:
use overload q\""\=>"bar::baz";
@bar::ISA = foo;
sub foo::baz{a}
warn bless[]
__END__
Undefined subroutine &bar::baz called at - line 4.
But apostrophes work as documented:
use overload q\""\=>"bar'baz";
@bar::ISA = foo;
sub foo::baz{a}
warn bless[]
__END__
a at - line 4.
I can’t see how the treatment of ::, introduced in a60067777, is not a
bug, though the method logic looks intentional:
+ if (not ref $sub and $sub !~ /::/) {
I suspect it was one of those things that was just not thought
through. The pre-a60067777 logic was in gv.c, and treated strings
containing package separators just like any other strings:
switch (SvTYPE(sv)) {
default:
if (!SvROK(sv)) {
if (!SvOK(sv)) break;
gv = gv_fetchmethod(stash, SvPV(sv, na));
if (gv) cv = GvCV(gv);
break;
}
cv = (CV*)SvRV(sv);
|
| |
|
|
|
|
|
| |
The test for undefining %overload:: no longer goes through the code
path that used to crash, because bless[] no longer updates overload
tables. That now happens when overload methods are called. So, even
if the bug were reintroduced, the test would pass without this change.
|
| |
|
|
|
| |
Added by 0bdaccee3 and partly corrected by b0bf6df7d, this comment had
me befuddled enough to have to read it three times.
|
| |
|
|
|
|
|
|
|
| |
This block of tests was added by commit d411a6a9eb in the middle
of the numify tests, separating the Numify package from the tests
that used it.
The diff makes it look as though the Numify package got moved down,
but I can assure you that I moved the perl31793 block *up*!
|
| |
|
|
|
|
|
| |
Since overloading itself now checks whether caches are up to date, and
since changes to the stash (@ISA, methods) turn the flag on and over-
loading itself turns the flag off when it can, sv_bless no longer
needs to deal with it at all.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, only classes that had no overloading defined could
inherit the fallback from other classes. If a subclass wanted to
override a single overload setting, it would have to specify the fall-
back value explicitly, to avoid implying fallback=>undef.
We do this by separating the fallback value from overloadedness
itself, so it is possible to have a class that is overloaded, but with
no fallback value.
Previously, the ‘()’ stash entry was used for two purposes. It had a
sub in it so it could be found using usual method lookup mechanims.
The failure to find any such method would be taken for efficiency’s
sake to mean that there was no overloaded, and the search for methods
could end early. The scalar slot contained the fallback entry itself.
To preserve the effiency, we still use &{"()"} to indicate that there
is overloadedness.
Fallback now uses its own entry, named ‘(fallback’. Since it
has to be special-cased anyway, there is no need to add it to
regen/overload.pl.
|
| |
|
|
|
| |
This is something I almost broke in trying to fix a bug in ‘no
overload "fallback"’.
|
| | |
|
| |
|
|
|
|
| |
If a non-overloaded class begins inheriting overloading due to @ISA
changes, we need to set the overloaded (AMAGIC) flag on the stash to
indicate that. Updating caches shouldn’t require a dummy blessing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of setting a class’s overloaded (HvAMAGIC) flag when bless
happens, we should do it in ‘use overload’. Otherwise, if a non-over-
loaded class gains overloading via ‘use overload’, existing objects
won’t get overloading until another object is blessed into the
same class.
Inherited overloading that is turned on due to @ISA changes still
won’t work yet. That will come in a later commit.
Doing this via %OVERLOAD magic would require referencing
the stash from magic. Since overload.pm already does
‘*{$package . "::()"} = \&nil’, triggering mro_method_changed_in,
the simplest approach is to turn on the stash’s AMAGIC flag in
mro_method_changed_in. Since, if there is no overloading, the flag
will be turned off on the next attempted overload call (in Gv_AM in
sv.h), there should be noticeable slowdown.
I had to turn off HvAMAGIC in hv_undef, to prevent ‘Can't use anony-
nous symbol table for method lookup’ from occurring when stringifying
an object whose package has been undefined.
|
| |
|
|
|
|
| |
Changing a non-overloaded class’s @ISA such that it starts inheriting
overloading should apply to objects already in that class, without
requiring an explicit ‘bless \$dummy’ to update things.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of checking whether overload tables are up to date only during
bless, do this check whenever using overloading.
This allows changes to methods and @ISA that affect overloading to
come into effect immediately, instead of requiring a dummy ‘bless[]’
to reset things. (This does not yet apply to @ISA changes that cause
non-overloaded classes to start inheriting overloading.)
This fixes a bug brought up in ticket #112708, though the original bug
still exists.
Some tests had to change, but those tests were checking to make sure
that caches could go stale and still be used, which made no sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By putting the flag on the stash, we can allow the overloaded status
of all objects of a particular class to change without having to
change the flag on every object (which would require traversing arenas
or keeping caches).
This partially fixes bug #112708, in that objects that existed before
their class had any overloading will start working after overloading
is introduced if other objects are blessed into that class.
Without blessings of other objects, they still don’t work yet. The
fix for that is yet to come....
This was also a good excuse for deleting a comment that contained two
typos. :-)
|
| |
|
|
|
|
|
|
|
|
|
| |
Changes to methods, @ISA, or overload settings should affect objects
that are already blessed into the class.
Currently, objects that existed before any overload settings were in
place do not do overloading at all (bug #112708). Objects that were
blessed when overload settings were in place are not affected by
changes to methods or @ISA until another object is blessed into the
same class.
|
| | |
|
