| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PL_markstack_ptr was read once to do the ++ and comparison. Then after
the markstack_grow call, or not, depending on the branch. The code reads
PL_markstack_ptr a 2nd time. It has to be reread in case (or always does)
markstack_grow reallocs the mark stack. markstack_grow has a void retval.
That is a waste of a register. Let us put it to use to return the new
PL_markstack_ptr. In markstack_grow the contents that will be assigned to
PL_markstack_ptr are already in a register. So let the I32* flow out from
markstack_grow to its caller.
In VC2003 32 bit asm, mark_stack_entry is register eax. The retval of
markstack_grow is in eax. So the assignment "=" in
"mark_stack_entry = markstack_grow();" has no overhead. Since the other,
not extend branch, is function call free,
"(mark_stack_entry = ++PL_markstack_ptr)" assigns to eax. Ultimatly with
this patch a 3 byte mov instruction is saved for each instance of PUSHMARK,
and 1 interp var read is removed. I observed 42 callers of markstack_grow
with my disassembler, so theoretically 3*42 bytes of machine code was
removed for me.
Perl_pp_pushmark dropped from 0x2b to 0x28 bytes of x86 VC 2003
machine code. [perl #122034]
|
| |
|
|
|
|
|
|
| |
I've gone through pp_hot.c and scope.c and added LIKELY() or UNLIKELY()
to all conditionals where I understand the code well enough to know that
a particular branch is or isn't likely to be taken very often.
I also processed some of the .h files which contain commonly used macros.
|
| |
|
|
|
|
| |
The macros assert_not_ROK(sv) and assert_not_glob(sv) are intended to be used
in expressions, and finish with a trailing comma, so they shouldn't have a ;
after them.
|
| |
|
|
|
|
|
|
| |
Currently it takes the 'clear-in-place' branch on lexical vars if
the ref count is <= 1. However, RC < 1 is a "should never happen"
condition, so rather than keeping that damaged var, take the other branch,
which will call SvREFCNT_dec() on it, which will Do the Right Thing
(like emitting a warning).
|
| |
|
|
|
|
| |
Add SVf_OOK to the list of flags that are handled in the 'slow' branch.
This allows us to avoid checking for hv_kill_backrefs() or sv_backoff()
for the majority of lexicals which won't require it.
|
| |
|
|
| |
the next commit will change thinks that affect only part of the macro
|
| |
|
|
|
|
|
|
|
|
|
| |
SAVEt_CLEARSV should always be called with SvPADMY() true, so don't test
for it, but assert it instead. Then change this:
if (SvPADMY(sv) && !SvFAKE(sv))
SvREADONLY_off(sv);
The SvPADMY() isn't needed, but we should test for RO-ness instead, to
avoid an unnecessary SvREADONLY_off().
|
| |
|
|
| |
whitespace-only changes
|
| |
|
|
|
|
|
|
| |
In the 'clear' branch of SAVEt_CLEARSV, there are several individual
if (SvSOMEFLAG(sv)) {...} tests. Wrap all these tests in a single
if (SvFLAGS(sv) & (union|of|all|flags)), so that for the common case
of boring lexicals that don't need special clear up, we can skip all the
individual tests
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of ticket #119295.
Commit 7fa949d (5.19.3) allowed copy-on-write with compile-time con-
stants. That caused this to fail:
use Variable::OnDestruct:
{
my $h = "foo";
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
It prints undef instead of foo.
It turns out this is much older:
use Variable::OnDestruct;
{
my $h = __PACKAGE__;
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
This one prints undef starting with 5.17.3 (a6d7a4ac1).
But even before that, this prints undef:
use Variable::OnDestruct;
{
my $h = \1;
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
In all these cases, the scalar is getting undefined before free magic
triggers (Variable::OnDestruct uses free magic).
Usually when a scalar is freed, the magic is triggered before anything
else. When a lexical scalar is ‘freed’ on scope exit (cleared for
reuse on scope entry), the order is different. References, globs and
copy-on-write scalars become undefined (via sv_force_normal) before
magic is triggered.
There is no reason for the order to be different here, and it causes
unpredictable behaviour (you never know when you will or will not have
a cow). So change the order in scope exit to match regular freeing.
|
| |
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I am referring to what is usually known simply as The Stack.)
This partially fixes #119161.
By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all. Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.
I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for #119161.
On 64-bit platforms, I32 is too small to hold offsets into a stack
that can grow larger than I32_MAX. What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices, corrupting memory, and causing crashes.
With this commit, ()=1..1000000000000 stops crashing immediately.
Instead, it gobbles up all your memory first, and then, if your com-
puter still survives, crashes. The second crash happesn bcause of
a similar bug with the argument stack, which the next commit will
take care of.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c82ecf346.
It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread. So when you free the cop, how do you know where to do
SvREFCNT_dec?
In reverting c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
|
| |
|
|
| |
81ed78b25c4b removed the only use of this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves having to allocate a separate string buffer for every cop
(control op; every statement has one).
Under non-threaded builds, every cop has a pointer to the GV for that
source file, namely *{"_<filename"}.
Under threaded builds, the name of the GV used to be stored instead.
Now we store an offset into the per-interpreter PL_filegvpad, which
points to the GV.
This makes no significant speed difference, but it reduces mem-
ory usage.
|
| |
|
|
|
|
|
|
|
| |
$ ./perl -Ilib -e '@a=1..2; eval { @a=sort{die} @a }; warn "ok so far\n"; @a = 1'
ok so far
Modification of a read-only value attempted at -e line 1.
If something goes wrong inside the sort block and it dies, we still
need to make sure we turn off the read-only flag on that array.
|
| |
|
|
|
|
|
|
|
|
| |
This is a struct that holds all the global state of the current regex
match.
The previous set of commits have gradually removed all the fields of this
struct (by making things local rather than global state). Since the struct
is now empty, the PL_reg_state var can be removed, along with the
SAVEt_RE_STATE save type which was used to save and restore those fields
on recursive re-entry to the regex engine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate these two global vars (well, fields in the global
PL_reg_state), that hold the regex super-liner cache.
PL_reg_poscache_size gets replaced with a field in the local regmatch_info
struct, while PL_reg_poscache (which needs freeing at end of pattern
execution or on croak()), goes in the regmatch_info_aux struct.
Note that this includes a slight change in behaviour.
Each regex execution now has its own private poscache pointer, initially
null. If the super-linear behaviour is detected, the cache is malloced,
used for the duration of the pattern match, then freed.
The former behaviour allocated a global poscache on first use, which was
retained between regex executions. Since the poscache could between 0.25
and 2x the size of the string being matched, that could potentially be a
big buffer lying around unused. So we save memory at the expense of a new
malloc/free for every regex that triggers super-linear behaviour.
The old behaviour saved the old pointer on reentrancy, then restored the
old one (and possibly freed the new buffer) at exit. Except it didn't for
(?{}), so /(?{ m{something-that-triggers-super-linear-cache} })/ would
leak each time the inner regex was called. This is now fixed
automatically.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PERL_ASYNC_CHECK() was added to Perl_leave_scope() as part of commit
f410a2119920dd04, which moved signal dispatch from the runloop to
control flow ops, to mitigate nearly all of the speed cost of safe
signals.
The assumption was that scope exit was a safe place to dispatch signals.
However, this is not true, as parts of the regex engine call
leave_scope(), the regex engine stores some state in per-interpreter
variables, and code called within signal handlers can change these
values.
Hence remove the call to PERL_ASYNC_CHECK() from Perl_leave_scope(), and
add it explicitly in the various OPs which were relying on their call to
leave_scope() to dispatch any pending signals. Also add a
PERL_ASYNC_CHECK() to the exit of the runloop, which ensures signals
still dispatch from S_sortcv() and S_sortcv_stacked(), as well as
addressing one of the concerns in the commit message of
f410a2119920dd04:
Subtle bugs might remain - there might be constructions that enter
the runloop (where signals used to be dispatched) but don't contain
any PERL_ASYNC_CHECK() calls themselves.
Finally, move the PERL_ASYNC_CHECK(); added by that commit to pp_goto to
the end of the function, to be consistent with the positioning of all
other PERL_ASYNC_CHECK() calls - at the beginning or end of OP
functions, hence just before the return to or just after the call from
the runloop, and hence effectively at the same point as the previous
location of PERL_ASYNC_CHECK() in the runloop.
|
| |
|
|
|
| |
The are lots of places where local vars aren't used when compiled
with NO_TAINT_SUPPORT.
|
| |
|
|
|
|
|
| |
Clang under Address sanitizer is showing several problems when building
Perl, having to do when a limit reaches I32_MAX. This commit fixes
those problems by doing special tests for I32_MAX, and preventing
overflow.
|
| |
|
|
| |
clang didn't like %ld on I32's.
|
| |
|
|
|
|
|
|
|
| |
Like SvREFCNT_dec(), but skips the not null check, making code potentially
smaller and faster.
Also as proof of concept, updates the SvREFCNT_dec's in scope.c where
it's obvious the value can't be NULL. There are still 500+ uses in the
perl core that need evaluating!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several places that have code similar to
if (SvMAGICAL(sv)) {
PL_localizing = 2;
SvSETMAGIC(sv)
PL_localizing = 0;
}
The condition is sub-optimal (it should only test for set magic), and the
SvSETMAGIC repeats a similar test.
Other places didn't have the outer condition, so they set PL_localizing
twice even when not needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large and hot function. The main problem with it is that
there is code to pop a few args repeated in just about every branch.
Also, there are a whole bunch of local vars (sv, av, hv, gv etc)
that are never all used simultaneously, but are really just there for
casting convenience. Together, they defeat the compiler's register
allocation algorithms (well, they did for gcc anyway).
We fix this by just declaring three general vars, arg0,1,2 of type ANY, and
move the popping code to above the switch(). We sort the SAVEt_*
indices in order of number of args, so it's quick to determine how many
args we need to pop for a particular type.
Together with the previous commits which added the SS_ADD_* macros, this
reduces the size of scope.o (-O2, gcc x86_64) by about 9% (threaded)
or 17% (unthreaded), and seems to speed up simple loops / function calls
by around 5%.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Both these functions were structured as
if (int will fit in type)
SS_ADD(...);
else
save_pushi32ptr(...)
Inline the call of the "long" version of the save. With refactoring, the
machine code (x86_64, gcc -O2) is no larger than before, and saves time
on the long version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current idiom for adding an entry to the savestack is
SSCHECK(3);
SSPUSHINT(...);
SSPUSHPTR(...);
SSPUSHUV(SAVEt_...);
Replace this with a new idiom:
{
dSS_ADD;
SS_ADD_INT(...);
SS_ADD_PTR(...);
SS_ADD_UV(SAVEt_...);
SS_ADD_END(3);
}
This is designed to be more efficient.
First, it defines some local vars, and defers updating PL_savestack_ix
to the end.
Second, it performs the 'is there space on the stack' check *after*
pushing. Doing the check last means that values in registers will have
been pushed and no longer needed, so don't need saving around the call to
grow. Also, tail-call elimination of the grow() can be done. These changes
reduce the code of something like save_pushptrptr() to half its former
size.
Of course, doing the size check *after* pushing means we must always
ensure there are SS_MAXPUSH free slots on the savestack */
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
local *foo=sub{} is done in two stages:
• First the local *foo localises the GP (the glob pointer, or list of
slots), setting a flag on the GV.
• Then scalar assignment sees the flag on the GV on the LHS and loca-
lises a single slot.
The slot localisation only stores on the savestack a pointer into the
GP struct and the old value. There is no reference to the GV.
To restore a method properly, we have to have a reference to the GV
when the slot localisation is undone.
So in this commit I have added a new save type, SAVEt_GVSLOT. It is
like SAVEt_GENERIC_SV, except it pushes the GV as well. Currently
it is used only for CVs, but I will need it for HVs and maybe
AVs as well.
It is possible for the unwinding of the slot localisation to affect
only a GV other than the one that is pushed, if glob assignments have
taken place since the local *foo. So we have to check whether the
pointer is inside the GP and use PL_sub_generation++ if it is not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was already working for those cases where *foo contained a sub
before and after localisation. For those cases where *foo had no sub
but localised assignment gave it one, method caches were not being
reset on scope exit.
case SAVEt_GP in scope.c:leave_scope needs to look at both GPs (glob
pointer, or list of glob slots), both from before and after the unlo-
calisation. If either has a sub, method caches need to be cleared.
This does not yet fix local *foo = sub {}, but I added a to-do
test for it. (This is more complicated, as localisation happens in
two seperate steps, the glob slot localisation storing no pointers to
the glob itself on the savestack.)
|
| |
|
|
|
|
|
|
|
|
| |
These are regressions from 5.8.
local *ISA was not updating isa caches. local *ISA = [] was updating
caches, but scope unwinding was not.
Both save_gp and leave_scope/SAVEt_GP need to check whether the glob
is named ISA and call mro_isa_changed_in if appropriate.
|
| |
|
|
|
|
|
| |
save_gp was trying to call mro_method_changed_in even if the stash had
been detached.
This is a regression from 5.12.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new MRO stuff in 5.10 made PL_sub_generation++ mostly unnecessary,
and almost all uses of it were replaced with mro_method_changed_in.
There is only one problem: That doesn’t actually work properly. After
glob-to-glob assignment (*foo = *bar), both globs share the same GP
(glob pointer, or list of glob slots). But there is no list of GVs
associated with any GP. So there is no way, given a GV whose GP
is shared, to find out what other classes might need their method
caches reset.
sub B::b { "b" }
*A::b = *B::b;
@C::ISA = "A";
print C->b, "\n"; # should print "b"
eval 'sub B::b { "c" }';
print C->b, "\n"; # should print "c"
__END__
$ perl5.8.9 foo
b
c
$ perl5.10.0 foo
b
b
And it continues up to 5.16.x.
If a GP is shared, then those places where mro_method_changed_in is
called after the GP has been modified must do PL_sub_generation++
instead if the GP is shared, which can be detected through its refer-
ence count.
|
| |
|
|
|
| |
This has been redundant since ERRSV was changed to use GvSVn in com-
mit f5fa9033b8.
|
| |
|
|
|
|
|
| |
This finishes the removal of register declarations started by
eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in
function parameter declarations, and didn't include things in dist, ext,
and lib, which this does include
|
| |
|
|
|
| |
This assertion helped me to find and fix a crashing bug, so I don’t
want it to be removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
svp is a pointer to a pad array slice. It is derefed to set a sv flag.
It's optimized scope previous extended past the savestack_grow call. By
moving the flag setting before any calls in save_clearsv, svp does not have
to be carried across any calls. On some platforms there will be a benefit
(args transfered in vol regs for example, AMD64 Win64), on others none
since it will be reread from the stack after any child call anyway. I
assume the SvPADSTALE_off flag will have no effect on the panic croak.
After this commit, the only auto var carried through a call is
offset_shifted (and unavoidably my_perl).
I saw a drop in the size of save_clearsv from 0x5A to 0x58. The saving
and use of 1 nonvol reg on x86 32 bit VC 2003 was reduced, total stack
frame reduced by 1 pointer, since VC 2003 read svp off the stack only
once at the start of save_clearsv and kept it in a nonvol reg for the rest
of this func's body.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
local $_[0] puts the current $_[0] on to the savestack and gives the
array a brand new SV. If the array is not marked REAL, it holds no
reference counts on its elements. @_ is surreal by default.
The localisation code was making @_ hold a reference count on its new
element. The restore code was assuming it had a reference count, so
everything worked out if $_[0] was not modified after localisation.
But if the array is surreal, then modifications to it will assume that
it does *not* hold a reference count on $_[0]. So doing shift, or
@_=undef would cause the new element to leak.
Also, taking a reference to the array (\@_) will trigger, making
the reference count of all elements increeas, likwies leaking the
new element.
Since there is only one REAL flag, which indicates that all elements
of the array are reference-counted, we cannot have some elements ref-
erence-counted and some not (which local $_[0] does), and have every-
thing behave correctly.
So the only solution is to reify arrays before localising
their elements.
|
| |
|
|
|
| |
The previous commit added a loop round a block of code; now increase
the indent of the body of the loop.
|
| |
|
|
|
| |
Add a new save type that does the equivalent of multiple SAVEt_CLEARSV's
for a given target range. This makes the new padange op more efficient.
|
| |
|
|
| |
A '&' got lost in the conversion
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By defining NO_TAINT_SUPPORT, all the various checks that perl does for
tainting become no-ops. It's not an entirely complete change: it doesn't
attempt to remove the taint-related interpreter variables, but instead
virtually eliminates access to it.
Why, you ask? Because it appears to speed up perl's run-time
significantly by avoiding various "are we running under taint" checks
and the like.
This change is not in a state to go into blead yet. The actual way I
implemented it might raise some (valid) objections. Basically, I
replaced all uses of the global taint variables (but not PL_taint_warn!)
with an extra layer of get/set macros (TAINT_get/TAINTING_get).
Furthermore, the change is not complete:
- PL_taint_warn would likely deserve the same treatment.
- Obviously, tests fail. We have tests for -t/-T
- Right now, I added a Perl warn() on startup when -t/-T are detected
but the perl was not compiled support it. It might be argued that it
should be silently ignored! Needs some thinking.
- Code quality concerns - needs review.
- Configure support required.
- Needs thinking: How does this tie in with CPAN XS modules that use
PL_taint and friends? It's easy to backport the new macros via PPPort,
but that doesn't magically change all code out there. Might be
harmless, though, because whenever you're running under
NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false.
Thus, the only CPAN code that SHOULD be adversely affected is code
that changes taint state.
|
| |
|
|
| |
This reverts commit d2c8bf052f5a8bb99050f6d2418d77151eb4b468.
|
| |
|
|
| |
Contexts are no longer what they used to be back in 1996.
|
| |
|
|
|
| |
The third argument to PoisonNew is the type, not the size. Also, poisoning
the contents of the sv itself is incorrect.
|
| |
|
|
|
| |
This assignment looks really rather like overzealous cleanliness.
It's a hot path. Now it's death by 999 cuts instead of 1000.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
my subs are cloned on scope entry. To make closures work, a stub
stored in the pad (and closed over elsewhere) is cloned into.
But we need somewhere to store the prototype from which the clone is
made. I was attaching the prototype via magic to the stub in the pad,
since the pad is available at run time, but not the pad names.
That leads to lots of little games all over the place to make sure
the prototype isn’t lost when the pad is swiped on scope exit
(SAVEt_CLEARSV in scope.c). We also run the risk of losing it if an
XS module replaces the sub with another.
Instead, we should be storing it with the pad name. The previous com-
mit made the pad names available at run time, so we can move it there
(still stuffed inside a magic box) and delete much code.
This does mean that newMYSUB cannot rely on the behaviour of non-clon-
able subs that close over variables (or subs) immediately. Previ-
ously, we would dig through outer scopes to find the stub in cases
like this:
sub y {
my sub foo;
sub x {
sub {
sub foo { ... }
}
}
}
We would stop at x, which happens to have y’s stub in its pad, so
that’s no problem.
If we attach it to the pad name, we definitely have to dig past x to
get to the pad name in y’s pad.
Usually, immediate closures do not store the parent pad index, since
it will never be used. But now we do need to use it, so we modify the
code in pad.c:S_pad_findlex to set it always for my/state.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pad slot for a my sub now holds a stub with a prototype CV
attached to it by proto magic.
The prototype is cloned on scope entry. The stub in the pad is used
when cloning, so any code that references the sub before scope entry
will be able to see that stub become defined, making these behave
similarly:
our $x;
BEGIN { $x = \&foo }
sub foo { }
our $x;
my sub foo { }
BEGIN { $x = \&foo }
Constants are currently not cloned, but that may cause bugs in
pad_push. I’ll have to look into that.
On scope exit, lexical CVs go through leave_scope’s SAVEt_CLEARSV sec-
tion, like lexical variables. If the sub is referenced elsewhere, it
is abandoned, and its proto magic is stolen and attached to a new stub
stored in the pad. If the sub is not referenced elsewhere, it is
undefined via cv_undef.
To clone my subs on scope entry, we create a sequence of introcv and
clonecv ops. See the huge comment in block_end that explains why we
need two separate ops for each CV.
To allow my subs to be defined in inner subs (my sub foo; sub { sub
foo {} }), pad_add_name_pvn and S_pad_findlex now upgrade the entry
for a my sub to a CV to begin with, so that fake entries added to pads
(fake entries are those that reference outer pads) can share the same
CV. Otherwise newMYSUB would have to add the CV to every pad that
closes over the ‘my sub’ declaration. newMYSUB no longer throws away
the initial value replacing it with a new one.
Prototypes are not currently visible to sub calls at compile time,
because the lexer sees the empty stub. A future commit will
solve that.
When I added name heks to CV’s I made mistakes in a few places, by not
turning on the CVf_NAMED flag, or by not clearing the field when free-
ing the hek. Those code paths were not exercised enough by state
subs, so the problems did not show up till now. So this commit fixes
those, too.
One of the tests in lexsub.t, involving foreach loops, was incorrect,
and has been fixed. Another test has been added to the end for a par-
ticular case of state subs closing over my subs that I broke when ini-
tially trying to get sibling my subs to close over each other, before
I had separate introcv and clonecv ops.
|
