summaryrefslogtreecommitdiff
path: root/op.c
Commit message (Collapse)AuthorAgeFilesLines
* Note what incrementing the op_type actually doesRafael Garcia-Suarez2013-02-271-0/+2
| | | | This comment is intended to improve the greppability of the code.
* put an experimental warning on lexical topicRicardo Signes2013-02-201-0/+7
|
* Un-deprecate the support for lexical $_Rafael Garcia-Suarez2013-02-201-7/+0
|
* pmruntime(): change '=' to '==' in an assertionDavid Mitchell2013-01-301-1/+1
| | | | | | | Whoops! Probably harmless, since if the thing it was intended to assert for was indeed true, then the assignment would be a noop anyway.
* pmruntime(): rename var to avoid macro name clashDavid Mitchell2013-01-301-9/+9
| | | | | | | [perl #116557] Apparently MS's WinCE SDK #defines 'leave'. So rename the 'leave' variable to 'leaveop' to avoid clashes.
* Change core calls of isALNUM() to isWORDCHAR()Karl Williamson2012-12-311-2/+2
| | | | The latter is more clearly named to indicate it includes the underscore.
* Copy keys for aassign in lvalue subFather Chrysostomos2012-12-111-2/+3
| | | | | | | | | Checking LVRET (which pp_aassign does, as of a few commits ago) has no effect if OPpMAYBE_LVSUB is not set on the op. This com- mit changes op.c:op_lvalue_flags to set this flag on aassign ops. This makes sub:lvalue{%h=($x,$x)} behave correctly if the return values of the sub are assigned to ($x is unmodfied).
* Stop using PL_glob_index for PL_globhookFather Chrysostomos2012-12-091-3/+0
| | | | | | If Glob.xs just uses the address of PL_op as its iterator key all the time (when called via PL_globhook too, not just via a glob override), the code is simpler.
* Don’t pass PL_glob_index to glob overridesFather Chrysostomos2012-12-091-3/+1
| | | | | | | | This magic second argument is undocumented and unused on CPAN and in the core (as of the last few commits). It could also get in the way of making glob truly overridable in the future (e.g., allowing File::Glob to take a list).
* Convert some SvREFCNT_dec's to SvREFCNT_dec_NN's for efficiencySteffen Mueller2012-12-091-6/+6
|
* Stop renamed packages from making reset() crashFather Chrysostomos2012-12-051-15/+2
| | | | | | | | | | | | | | | | | | This only affected threaded builds. I think the comments in the added test explain well enough what was happening. The solution is to store a stashpad offset in the pmop, instead of the name of the stash. This is similar to what was done with cop stashes in d4d03940c58a. Not only does this fix the crash, but it also makes compilation faster and saves memory (no separate malloc for every m?pat?). I had to move Safefree(PL_stashpad) later on in perl_destruct, because freeing a pmop causes the PL_stashpad to be accessed, and pmops can be freed during sv_clean_all. Its previous location was not a problem for cops, as PL_stashpad[cop->cop_stashoff] is only accessed when PL_curcop==that_cop and Perl code is running, not when cops are freed.
* Don’t use PMf_ONCE flag for split-to-arrayFather Chrysostomos2012-12-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the PMf_ONCE flag has two purposes. It is used to indicate that m?? must match only once. That’s what distinguishes m?? and m// internally. The other use indicates that @x = split... modifies the array in place. Whenever the split op is modified to point straight to the array, the PMf_ONCE flag is set. pp_split checks both whether there is an array attached to the op (via a GV in the pad under threads, or a pointer from the op to the GV under non-threaded builds) and whether the flag is set. This makes the flag redundant in the split case. Removing its use here not only simplifies the code and removes redun- dant bit-fiddling, but also makes this comment in toke.c, added by ad639bfb6, come true: /* This is the only point in the code that sets PMf_ONCE: */ (That was actually harmless, as it doesn’t hurt to have a stash refer- ring to pmops that don’t use the PMf_USED flag, and the PMf_ONCE flag is set for split way after that code is run. It is also unnecessary for split, as that bookkeeping code in toke.c only applies to the m?? use of PMf_ONCE.) This commit also removes a gimme != G_ARRAY check that thas been redundant since a6d8037e26a.
* Deprecate lexical $_Father Chrysostomos2012-12-041-0/+7
| | | | | | | See tickets #114020 and #75598 for why. The changes to tests in cpan/Text-Tabs have been submitted upstream at rt.cpan.org #81698.
* Stop newCONSTSUB from leaking the constant under fatal warningsFather Chrysostomos2012-11-301-1/+4
|
* Reset method caches when GPs are sharedFather Chrysostomos2012-11-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix comment referencing pp_iterinit (should be pp_enteriter)Matthew Horsfall (alh)2012-11-271-1/+1
|
* Remove "register" declarationsKarl Williamson2012-11-241-8/+8
| | | | | | | 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
* Stop sub decl redef warnings from leaking CVsFather Chrysostomos2012-11-241-0/+3
| | | | | | | | | When newMYSUB and newATTRSUB are called, PL_compcv has an unclaimed reference count, so any code that croaks must decrement the reference count or make arrangements for such to happen. This commit applies only to redefinition warnings triggered by sub declarations, like ‘sub foo {}’ and ‘my sub foo {}’.
* op.c: Factor common ‘existing sub’ logic into static routineFather Chrysostomos2012-11-241-81/+61
| | | | | | newMYSUB and newATTRSUB are very similar but differ in small ways throughout. This particular block of code is close enough it can be moved into a separate static routine to avoid repetition.
* Warn by default for constant my sub redefinitionFather Chrysostomos2012-11-241-1/+1
| | | | | | | I apparently never had this working and never tested it either. I was checking whether the new sub was a constant, rather than the one it was clobbering.
* op.c:newATTRSUB: Change an if condition to an elseFather Chrysostomos2012-11-241-5/+1
| | | | | | | | | In one spot we have if(blah blah balh) {...} followed by if (<exactly the opposite>). We can just change the second if to an else, since the condition is not going to change here. This brings newATTRSUB and newMYSUB slightly closer, allowing me to factor some of it out into a static routine in the next commit.
* Stop ignored :lvalue warning from leaking CVsFather Chrysostomos2012-11-241-0/+10
| | | | | | When newMYSUB and newATTRSUB are called, PL_compcv has an unclaimed reference count, so any code that croaks must decrement the reference count or make arrangements for such to happen.
* prevent multiple evaluations of ERRSVDaniel Dragan2012-11-231-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove a large amount of machine code (~4KB for me) from funcs that use ERRSV making Perl faster and smaller by preventing multiple evaluation. ERRSV is a macro that contains GvSVn which eventually conditionally calls Perl_gv_add_by_type. If a SvTRUE or any other multiple evaluation macro is used on ERRSV, the expansion will, in asm have dozens of calls to Perl_gv_add_by_type one for each test/deref of the SV in SvTRUE. A less severe problem exists when multiple funcs (sv_set*) in a row call, each with ERRSV as an arg. Its recalculated then, Perl_gv_add_by_type and all. I think ERRSV macro got the func call in commit f5fa9033b8, Perl RT #70862. Prior to that commit it would be pure derefs I think. Saving the SV* is still better than looking into interp->gv->gp to get the SV * after each func call. I received no responses to http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195724.html explaining when the SV is replaced in PL_errgv, so took a conservative view and assumed callbacks (with Perl stack/ENTER/LEAVE/eval_*/call_*) can change it. I also assume ERRSV will never return null, this allows a more efficiently version of SvTRUE to be used. In Perl_newATTRSUB_flags a wasteful copy to C stack operation with the string was removed, and a croak_notcontext to remove push instructions to the stack. I was not sure about the interaction between ERRSV and message sv, I didn't change it to a more efficient (instruction wise, speed, idk) format string combining of the not safe string and ERRSV in the croak call. If such an optimization is done, a compiler potentially will put the not safe string on the first, unconditionally, then check PL_in_eval, and then jump to the croak call site, or eval ERRSV, push the SV on the C stack then push the format string "%"SVf"%s". The C stack allocated const char array came from commit e1ec3a884f . In Perl_eval_pv, croak_on_error was checked first to not eval ERRSV unless necessery. I was not sure about the side effects of using a more efficient croak_sv instead of Perl_croak (null chars, utf8, etc) so I left a comment. nocontext used to save an push instruction on implicit sys perl. In S_doeval, don't open a new block to avoid large whitespace changes. The NULL assignment should optimize away unless accidental usage of errsv in the future happens through a code change. There might be a bug here from commit ecad31f018 since previous a char * was derefed to check for null char, but ERRSV will never be null, so "Unknown error\n" branch will never be taken. For pp_sys.c, in pp_die a new block was opened to not eval ERRSV if "well-formed exception supplied". The else if else if else blocks all used ERRSV, so a "SV * errsv = NULL;" and a eval in the conditional with comma op thing wouldn't work (maybe it would, see toke.c comments later in this message). pp_warn, I have no comments. In S_compile_runtime_code, a croak_sv question comes up same as in Perl_eval_pv. In S_new_constant, a eval in the conditional is done to avoid evaling ERRSV if PL_in_eval short circuits. Same thing in Perl_yyerror_pvn. Perl__core_swash_init I have no comments. In the future, a SvEMPTYSTRING macro should be considered (not fully thought out by me) to replace the SvTRUEs with something smaller and faster when dealing with ERRSV. _nomg is another thing to think about. In S_init_main_stash there is an opportunity to prevent an extra ERRSV between "sv_grow(ERRSV, 240);" and "CLEAR_ERRSV();" that was too complicated for me to optimize. before perl517.dll .text 0xc2f77 .rdata 0x212dc .data 0x3948 after perl517.dll .text 0xc20d7 .rdata 0x212dc .data 0x3948 Numbers are from VC 2003 x86 32 bit.
* SVf_IsCOWFather Chrysostomos2012-11-141-11/+6
| | | | | | | | | | | | | | | As discussed in ticket #114820, instead of using READONLY+FAKE to mark a copy-on-write string, we should make it a separate flag. There are many modules in CPAN (and 1 in core, Compress::Raw::Zlib) that assume that SvREADONLY means read-only. Only one CPAN module, POSIX::pselect will definitely be broken by this. Others may need to be tweaked. But I believe this is for the better. It causes all tests except ext/Devel-Peek/t/Peek.t (which needs a tiny tweak still) to pass under PERL_OLD_COPY_ON_WRITE, which is a prereq- uisite for any new COW scheme that creates COWs under the same cir- cumstances.
* Stop my subs with syntax errors from leakingFather Chrysostomos2012-11-141-0/+2
|
* op.c: Fix mad+POISON build under clangFather Chrysostomos2012-11-131-1/+1
|
* Fix assertion failures with anon subsFather Chrysostomos2012-11-131-5/+3
| | | | | | | | | | | In commit 9ffcdca1f50, I did not take into account that the newATTRSUB’s caller makes sure that the CV is freed if it is an anonymous sub. So I only needed to free the sub explicitly after a syntax error for a named sub. By returning 0 for anonymous subs as well, I ended up causing assertion failures. Why I wasn’t getting them before I don’t know, as I was using a debugging build.
* Don’t leak subs containing syntax errorsFather Chrysostomos2012-11-131-4/+6
| | | | | | | | | | | I fixed this for BEGIN blocks earlier, but missed the fact that all subs are affected. When called without an o argument (from newANONATTRSUB), newATTRSUB is expected to return a CV with an unowned reference count of which the caller will take ownership. We cannot have newATTRSUB returning a freed CV, so we have it return null instead. But that means ck_anoncode and pm_runtime have to account for that.
* Stop anon subs with bad attributes from leakingFather Chrysostomos2012-11-131-0/+2
|
* PADRANGE: don't assume targs are contiguousDavid Mitchell2012-11-121-4/+5
| | | | | | Normally in something like my($x,$y,$z), the 3 targs are contiguous; however eternal modules like Function::Parameters can break that assumption, so don't assume it.
* Consolidate any single pad ops after a padrangeDavid Mitchell2012-11-101-13/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given something like my ($a,$b); my $c; my $d; then after having detected that we can create a padrange op for $a,$b, extend it to include $c,$d too. Together with the previous commit that consolidates adjacent padrange ops, this means that any contiguous sequence of void 'my' declarations that starts with a list (i.e. my ($x,..) rather than my $x) will all be compressed into a single padrange op. For example my ($a,$b); my @c; my %d; my ($e,@f); becomes the two ops padrange[$a;$b;@c;%d;$e;@f] nextstate The restriction on the first 'my' being a list is that we only ever convert pushmarks into padranges, to keep things manageable (both for compiling and for Deparse). This simply means that my $x; my ($a,$b); my @c; my %d; my ($e,@f) becomes padsv[$x] nextstate padrange[$a;$b;@c;%d;$e;@f] nextstate
* Consolidate adjacent padrange opsDavid Mitchell2012-11-101-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In something like my ($a,$b); my ($c,$d); when converting $c,$d into a padrange op, check first whether we're immediately preceded by a similar padrange (and nextstate) op, and if so re-use the existing padrange op (by increasing the count). Also, skip the first nextstate and only use the second nextstate. So pushmark; padsv[$a]; padsv[$b]; list; nextstate 1; pushmark; padsv[$c]; padsv[$c]; list; nextstate 2; becomes padrange[$a,$b] nextstate 1; pushmark; padsv[$c]; padsv[$c]; list; nextstate 2; which then becomes padrange[$a,$b,$c,$d]; nextstate 2;
* padrange: handle @_ directlyDavid Mitchell2012-11-101-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | In a construct like my ($x,$y) = @_ the pushmark/padsv/padsv is already optimised into a single padrange op. This commit makes the OPf_SPECIAL flag on the padrange op indicate that in addition, @_ should be pushed onto the stack, skipping an additional pushmark/gv[*_]/rv2sv combination. So in total (including the earlier padrange work), the above construct goes from being 3 <0> pushmark s 4 <$> gv(*_) s 5 <1> rv2av[t3] lK/1 6 <0> pushmark sRM*/128 7 <0> padsv[$x:1,2] lRM*/LVINTRO 8 <0> padsv[$y:1,2] lRM*/LVINTRO 9 <2> aassign[t4] vKS to 3 <0> padrange[$x:1,2; $y:1,2] l*/LVINTRO,2 ->4 4 <2> aassign[t4] vKS
* add SAVEt_CLEARPADRANGEDavid Mitchell2012-11-101-0/+6
| | | | | 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.
* add padrange opDavid Mitchell2012-11-101-0/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This single op can, in some circumstances, replace the sequence of a pushmark followed by one or more padsv/padav/padhv ops, and possibly a trailing 'list' op, but only where the targs of the pad ops form a continuous range. This is generally more efficient, but is particularly so in the case of void-context my declarations, such as: my ($a,@b); Formerly this would be executed as the following set of ops: pushmark pushes a new mark padsv[$a] pushes $a, does a SAVEt_CLEARSV padav[@b] pushes all the flattened elements (i.e. none) of @a, does a SAVEt_CLEARSV list pops the mark, and pops all stack elements except the last nextstate pops the remaining stack element It's now: padrange[$a..@b] does two SAVEt_CLEARSV's nextstate nothing needing doing to the stack Note that in the case above, this commit changes user-visible behaviour in pathological cases; in particular, it has always been possible to modify a lexical var *before* the my is executed, using goto or closure tricks. So in principle someone could tie an array, then could notice that FETCH is no longer being called, e.g. f(); my ($s, @a); # this no longer triggers two FETCHES sub f { tie @a, ...; push @a, 1,2; } But I think we can live with that. Note also that having a padrange operator will allow us shortly to have a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple individual SAVEt_CLEARSV's.
* Add C define to remove taint support from perlSteffen Mueller2012-11-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Stop the glob operator from leaking GVsFather Chrysostomos2012-11-041-1/+3
| | | | | | | | It was adding GVs to the symbol table (via newGVgen), so they would never be freed, even after the op was freed, unless done so explicitly. There is no reason for these GVs to be exposed.
* op.c:opslab_force_free: Make paranoid code reflect realityFather Chrysostomos2012-11-041-2/+1
| | | | | | | | | | When opslab_force_free is called, the CV still has a reference count on the slab. In fact, we don’t even bother lowering it if all goes well, but simply free the slab with the reference count set to 1. So the paranoid code that increments the reference count before free- ing an op is not necessary. Also, the shortcut out of the loop was never triggered, as it was checking for a reference count of 0, rather than 1.
* op.c: Stop SAVEFREEOP from leaking slabsFather Chrysostomos2012-11-041-0/+2
| | | | | | | | | | | | When a CV is freed prematurely, it cleans up its op slab. But SAVEFREEOP may cause the savestack to point to an op in that slab after the CV has been freed, so SAVEFREEOP is allowed to coun- termand the freeing of the slab. Every op that is not on the savestack is freed. The reference count of the slab was being left off by one. The result was that when the stack unwinding freed the op, it would leave the slab behind and leak it.
* Don’t leak BEGIN blocks after syntax errorsFather Chrysostomos2012-11-041-1/+3
|
* Allow regexp-to-pvlv assignmentFather Chrysostomos2012-10-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since the xpvlv and regexp structs conflict, we have to find somewhere else to put the regexp struct. I was going to sneak it in SvPVX, allocating a buffer large enough to fit the regexp struct followed by the string, and have SvPVX - sizeof(regexp) point to the struct. But that would make all regexp flag-checking macros fatter, and those are used in hot code. So I came up with another method. Regexp stringification is not speed-critical. So we can move the regexp stringification out of re->sv_u and put it in the regexp struct. Then the regexp struct itself can be pointed to by re->sv_u. So SVt_REGEXPs will have re->sv_any and re->sv_u pointing to the same spot. PVLVs can then have sv->sv_any point to the xpvlv body as usual, but have sv->sv_u point to a regexp struct. All regexp member access can go through sv_u instead of sv_any, which will be no slower than before. Regular expressions will no longer be SvPOK, so we give sv_2pv spec- ial logic for regexps. We don’t need to make the regexp struct larger, as SvLEN is currently always 0 iff mother_re is set. So we can replace the SvLEN field with the pv. SvFAKE is never used without SvPOK or SvSCREAM also set. So we can use that to identify regexps.
* Re-enable static op allocation with obslabReini Urban2012-10-251-1/+2
| | | | | | obslab and the removal of the op_latefree logic, which allowed static ops, removed support for the compiler modules, which allocates ops statically. Add an op_static flag to replace the old latefree(d) op_free logic.
* Disable const repl optimisation for empty patternFather Chrysostomos2012-10-111-0/+1
| | | | | | s//$a/ cannot assume that the $a expression is going to return the same value at each iteration, because the last-used pattern may con- tain code blocks that clobber *a.
* Use const repl optimisation with s///e where possibleFather Chrysostomos2012-10-111-12/+22
| | | | | | | | | | | | | | In those cases where s///e contains a single variable or a sequence that is folded to a const op, we can do away with substcont. PMf_EVAL means that there was an /e. But we don’t actually need to check that; instead we can just examine the op tree, which we have to do anyway. The op tree that s//$x/e and s//"constant"/e compile down to have a null (a do-block) containing a scope op (block with a single state- ment, as opposed to op_leave which represents multiple statements) containing a null followed by the constant or variable.
* [perl #49190] Don’t prematurely optimise s/foo/bar$baz/Father Chrysostomos2012-10-111-43/+18
| | | | | | | | | | | | | | | | | | | | | | | $baz could be aliased to a package variable, so we do need to recon- catenate for every iteration of s///g. For s/// without /g, only one more op will be executed, so the speed difference is negligible. The only cases we can optimise in terms of skipping the evaluation of the ops on the rhs (by eliminating the substconst op) are s//constant/ and s//$single_variable/. Anything more complicated causes bugs. A recent commit made s/foo/$bar/g re-stringify $bar for each iteration (though without having to reevaluate the ops that return $bar). So we no longer have to special-case match vars at compile time. This means that s/foo/bar$baz/g will be slower (and less buggy), but s/foo/$1/g will be faster. This also caused an existing taint but in pp_subst to surface. If get-magic turns off taint on a replacement string, it should not be considered tainted. So the taint check on the replacement should come *after* the stringification. This applies to the constant replacement optimisation. pp_substcont was already doing this correctly.
* Remove PMf_MAYBE_CONSTFather Chrysostomos2012-10-111-3/+0
| | | | It was added in ce862d02d but has never been used.
* [perl #26986] Skip subst const repl optimisation for logopsFather Chrysostomos2012-10-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | pm_runtime iterates through the ops that make up the replacement part of s///, to see whether the ops on the rhs can have side effects or contain match vars (in which case they must only be evaluted after the pattern). If they do not have side-effects, the rhs is presumed to be constant and evaluated first, and then pp_subst hangs on to the return value and reuses it in each iteration of s///g. This iteration simply follows op_next pointers. Logops are not that simple, so it is possible to hide match vars inside them, resulting in incorrect optimisations: "g" =~ /(.)/; @l{'a'..'z'} = 'a'..'z'; $_ = "hello"; s/(.)/$l{$a||$1}/g; print; __END__ ggggg This commit skips the optimisation whenever a logop is present. This does not fix all the optimisation problems. See ticket #49190.
* Merge 2 gv_fetch* calls in Perl_newXS_len_flagsDaniel Dragan2012-10-071-7/+5
| | | | | | | | Merge a gv_fetchpvn and a gv_fetchpv. A strlen call is avoided in gv_fetchpv, and in Perl_newXS_len_flags shorter machine code because 2 different call destinations were merged to 1, and "GV_ADDMULTI | flags,SVt_PVCV" arguments are unconditionally executed and are not in a branch.
* fix -DPERL_GLOBAL_STRUCT build failure introduced in 97b03d64 and e10681aaTony Cook2012-09-281-0/+1
|
* Restore special blocks to working orderFather Chrysostomos2012-09-261-6/+5
| | | | | | | | | | | | | | | | | | I accidentally broke these in commit 85ffec3682, yet everything passed for me under threads+mad. PL_compcv is usually restored to its previous value at the end of newATTRSUB when LEAVE_SCOPE is called. But BEGIN blocks are called before that. I needed PL_compcv to be restored to its previ- ous value before it was called, so I added LEAVE_SCOPE before process_special_blocks. But that caused the name to be freed before S_process_special_blocks got a chance to look at it. So I have now added a new parameter to S_process_special_blocks to allow *it* to call LEAVE_SCOPE after it determines that it is a BEGIN block, but before it calls it.
View Lorry Controller Status