summaryrefslogtreecommitdiff
path: root/scope.c
Commit message (Collapse)AuthorAgeFilesLines
* First stab at lexical scalar aliasesFather Chrysostomos2014-10-101-2/+0
| | | | | | | | | | | | | | | No \my$x= yet. Only my $x; \$x =.... It does not work properly with variables closed over from outside; hence, all the to-do tests fail still, since they do the assign- ment in evals. But this much works: $ ./miniperl -Ilib -Mfeature=:all -e 'my $m; \$m = \$n; warn \$m; warn \$n' Lvalue references are experimental at -e line 1. SCALAR(0x7fa04b805510) at -e line 1. SCALAR(0x7fa04b805510) at -e line 1.
* optimize & rmv from public API Perl_tmps_grow and related codeDaniel Dragan2014-10-101-5/+24
| | | | | | | | | | | | | | | | | | | Previously in PUSH_EXTEND_MORTAL__SV_C, "PL_tmps_ix + 1" would execute twice, once for the nonmutable if(>=), then again after the potential tmps_grow call. tmps_grow has an unused return register/void proto, put it to use by returning ix. Also change tmps_grow to take the result of "PL_tmps_ix + the constant (usually 1) or non-constant (EXTEND_MORTAL)". This avoid having to put the constant twice in machine code, once for the if test, 2nd time for extend length param for tmps_grow call. For non-constant/EXTEND_MORTAL usage, it allows the C optimizer to have the length var to go out of liveness sooner if possible. Also the var used for the if(>=) test is more likely to be in a register than length var. So "if test variable" is closer on hand to the CPU than length var. In some cases, if non-const len var isn't used again, it becomes the "ix" variable by having PL_tmps_ix added to it. Change sv_2mortal to return sv instead of NULL to remove a unique branch/block of machine code that assigns 0 to return variable (Visual C didn't figure out return sv == returned NULL, not sv). See also [perl #121845].
* Make list assignment respect foreach aliasingFather Chrysostomos2014-10-021-0/+12
| | | | | | | | | | | | See ff2a62e0c8 for the explanation. The bug fix in that commit did not apply to foreach’s aliasing. In short, ($a,$b)=($c,$d) needs to account for whether two of those variable names could be referring to the same variable. This commit causes the test suite to exercise a code path in scope.c added by ff2a62e0c8, which turned out to be buggy. (I forgot to test it at the time.)
* Remove most uses of PADMYFather Chrysostomos2014-09-241-1/+1
| | | | SVs_PADMY is now 0, and SvPADMY means !SvPADTMP.
* Stop setting PADMY; renumber PADSTALEFather Chrysostomos2014-09-241-1/+0
| | | | | | | | | | | | | | | | | | | | The PADMY flag was originally used on values stored in pads as a way to mark those slots ase being in use already during pad allocation. That changed for the most part all the way back in bbce6d6978 (perl5.003_09), but vestiges still remained, because some ops used PADMY for their targets. I removed the last one yesterday in 14d91147. So the PADMY flag now serves no purpose. At run time, the sole purpose of PADMY is to determine the meaning of the flag bit shared by PADTMP and PADSTALE. If PADMY is set, the flag means the latter. Instead of that more complicated check, we can just renumber PADSTALE to use the PADMY bit and assume that anything not PADTMP is PADMY. This commit changes the flags and does just enough to get tests passing (except Peek.t). fixup for padmy flag renumbering
* [perl #115254] Fix flag check on scope exitFather Chrysostomos2014-09-201-1/+1
| | | | | | | | | | | $ ./perl -Ilib -e '{ my $x = 3; Internals::SvREADONLY $x, 1; () }' $ ./perl -Ilib -e '{ my $x = ${qr//}; Internals::SvREADONLY $x, 1; () }' Modification of a read-only value attempted at -e line 1. The latter causes $x to be marked FAKE. At the time this code was introduced in scope.c, read-only+fake meant cow, so the !fake check was necessary. (That said, it has always behaved incorrectly for glob copies that are also marked fake.)
* Implement the bipolar read-only systemFather Chrysostomos2014-09-201-1/+1
| | | | | | | | | | | | | | | | | | | | | This fixes bugs related to Hash::Util::unlock accidentally unlocking internal scalars (e.g., that returned by undef()) and allowing them to be modified. Internal read-only values are now marked by two flags, the regular read-only flag, and the new ‘protected’ flag. Before this SvREADONLY served two purposes: 1) The code would use it to protect things that must not be modi- fied, ever (except when the core sees fit to do so). 2) Hash::Util and everybody else would use it to make this unmodifia- ble temporarily when requested by the user. Internals::SvREADONLY serves the latter purpose and only flips the read-only flag, so things that need to stay read-only will remain so, because of the ‘other’ read-only flag, that CPAN doesn’t know about. (If you are a CPAN author, do not read this.)
* Skip no-common-vars optimisation for aliasesFather Chrysostomos2014-09-181-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ‘no common vars’ optimisation allows perl to copy the values straight from the rhs to the lhs in a list assignment. In ($a,$b) = ($c,$d), that means $c gets assigned to $a, then $d to $b. If the same variable occurs on both sides of the expression (($a,$b)=($b,$a)), then it is necessary to make temporary copies of the variables on the rhs, before assigning them to the left. If some variables have been aliased to others, then the common vars detection can be fooled: *x = *y; $x = 3; ($x, $z) = (1, $y); That assigns 1 to $x, and then goes to assign $y to $z, but $y is the same as $x, which has just been clobbered. So 1 gets assigned instead of 3. This commit solves this by recording in each typeglob whether the sca- lar is an alias of a scalar from elsewhere. If such a glob is encountered, then the entire expression is ‘tainted’ such that list assignments will assume there might be common vars.
* Unused return value.Jarkko Hietaniemi2014-09-181-1/+1
|
* op.c:ck_subr: reify GVs based on call checkerFather Chrysostomos2014-09-151-15/+7
| | | | | | | | | | | | | | | Instead of faking up a GV to pass to the call checker if we have a lexical sub, just get the GV from CvGV (since that will reify the GV, even for lexical subs), unless the call checker has not specifically requested GVs. For now, we assume the default call checker cannot handle non-GV sub names, as indeed it cannot. An imminent commit will rectify that. The code in scope.c was getting the name hek from the proto CV (stowed in magic on the pad name) if the CV in the pad had lost it. Now, the proto CV can lose it at compile time via CvGV, so that does not work anymore. Instead, just get it from the GV.
* Turn on CVf_LEXICAL for lexical subsFather Chrysostomos2014-09-151-0/+2
| | | | | This flag will signify that lexical subs should not have package names associated with them in error messages, etc.
* avoid local *f = \&foo resetting the method cachesyber2014-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | { local *MyClass::func = sub {...}; # LINE A ... } # LINE B This example caused global method cache reset at both lines A and B because glob_assign_ref and leave_scope thought that GV's GP refcnt was 2 (because of saving to Save Stack). Issue has been fixed. SAVEt_GVSLOT (on leave_scope) now requires refcnt > 2 to reset cache globally). Additionally, glob_assign_ref when GvINTRO is set temporarily decrements gp's refcnt by 1. This handles all common cases, however there are still uncommon use cases when perl still resets cache globally, for example: { local *MyClass::func = sub {...}; # OK *MyClass::func = sub {...}; # OOPS :( } # OK or { local *MyClass::func = sub {...}; # OK { local *MyClass::func = sub {...}; # OOPS :( } # OOPS :( } # OK * OOPS is a line where global cache reset occurs * OK - one package cache reset
* Fix crash in leave_scope when my sub has CvGVFather Chrysostomos2014-08-281-3/+17
| | | | | | | Sub declaration can reuse an existing stub. So it is possible to define a package sub using a stub that was originally lexical. Hence, leave_scope needs to take into account that a my-sub may not have a name hek any more.
* Remove or downgrade unnecessary dVAR.Jarkko Hietaniemi2014-06-251-62/+1
| | | | | | | | You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference. (g++ does not do the "post-annotation" form of "unused".) The version code has some of these issues, reported upstream.
* remove 1 read of interp var from PUSHMARKDaniel Dragan2014-06-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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]
* sprinkle LIKELY() on pp_hot.c scope.c and some *.hDavid Mitchell2014-03-121-27/+27
| | | | | | | | 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.
* Commit 5c85b638cb45ea2b inadvertently broke the -DDEBUGGING build.Nicholas Clark2014-03-011-2/+5
| | | | | | 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.
* SAVEt_CLEARSV: only clear-in-place if RC==1David Mitchell2014-02-281-1/+1
| | | | | | | | 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).
* SAVEt_CLEARSV: handle SvOOK() speciallyDavid Mitchell2014-02-281-7/+10
| | | | | | 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.
* SAVEt_CLEARSV: expand SvOK_off() macroDavid Mitchell2014-02-281-1/+5
| | | | the next commit will change thinks that affect only part of the macro
* SAVEt_CLEARSV: simplify SvREADONLY_off() conditionDavid Mitchell2014-02-281-1/+3
| | | | | | | | | | | 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().
* SAVEt_CLEARSV: reindent after previous commitDavid Mitchell2014-02-281-17/+16
| | | | whitespace-only changes
* SAVEt_CLEARSV: check common flagsDavid Mitchell2014-02-281-2/+14
| | | | | | | | 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
* op.c:leave_scope: use mg_free before sv_force_normalFather Chrysostomos2013-09-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use SSize_t for arraysFather Chrysostomos2013-08-251-8/+16
| | | | | | | | | | 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.
* Use SSize_t when extending the stackFather Chrysostomos2013-08-251-1/+1
| | | | | | | | | | | | | | | | (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).
* Use SSize_t for tmps stack offsetsFather Chrysostomos2013-08-251-2/+19
| | | | | | | | | | | | | | | 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.
* Revert "[perl #117855] Store CopFILEGV in a pad under ithreads"Father Chrysostomos2013-08-091-5/+0
| | | | | | | | | | | | 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.
* Remove SAVEt_STACK_CXPOSFather Chrysostomos2013-08-051-3/+0
| | | | 81ed78b25c4b removed the only use of this.
* [perl #117855] Store CopFILEGV in a pad under ithreadsFather Chrysostomos2013-08-051-0/+5
| | | | | | | | | | | | | | | | 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.
* In-place sort should not leave array read-onlyFather Chrysostomos2013-06-261-0/+3
| | | | | | | | | $ ./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.
* eliminate PL_reg_stateDavid Mitchell2013-06-021-11/+0
| | | | | | | | | | 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 PL_reg_poscache, PL_reg_poscache_sizeDavid Mitchell2013-06-021-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove PERL_ASYNC_CHECK() from Perl_leave_scope().Nicholas Clark2013-05-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* silence warnings under NO_TAINT_SUPPORTDavid Mitchell2013-05-091-1/+3
| | | | | The are lots of places where local vars aren't used when compiled with NO_TAINT_SUPPORT.
* Fix some ASAN-identified problemsGeorge Greer2013-03-121-2/+2
| | | | | | | 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.
* scope.c: silence some compiler warningsDavid Mitchell2012-12-061-2/+3
| | | | clang didn't like %ld on I32's.
* add SvREFCNT_dec_NN()David Mitchell2012-12-041-6/+6
| | | | | | | | | 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!
* Optimise magic handling in save* and leave_scopeDavid Mitchell2012-12-041-19/+25
| | | | | | | | | | | | | | | 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.
* refactor Perl_leave_scopeDavid Mitchell2012-12-041-204/+196
| | | | | | | | | | | | | | | | | | | 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%.
* save_int/i32 inline the long versionDavid Mitchell2012-12-041-16/+24
| | | | | | | | | | | | | 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.
* Add SS_ADD_* macros and replace most SSPUSH* usesDavid Mitchell2012-12-041-57/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 */
* Clear method caches when unwinding local *foo=sub{}Father Chrysostomos2012-11-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Clear method caches when unwinding local *foo=*methodFather Chrysostomos2012-11-291-4/+8
| | | | | | | | | | | | | | | | 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.)
* Fix two local *ISA bugsFather Chrysostomos2012-11-291-5/+16
| | | | | | | | | | 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.
* Don’t croak for local *DetachedStash::methodFather Chrysostomos2012-11-291-1/+2
| | | | | | | save_gp was trying to call mro_method_changed_in even if the stash had been detached. This is a regression from 5.12.
* Reset method caches when GPs are sharedFather Chrysostomos2012-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* scope.c:save_gp: Remove redundant codeFather Chrysostomos2012-11-291-8/+0
| | | | | This has been redundant since ERRSV was changed to use GvSVn in com- mit f5fa9033b8.
* Remove "register" declarationsKarl Williamson2012-11-241-1/+1
| | | | | | | 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
* scope.c: Remove XXX tmp comment from SAVEt_FREEOPFather Chrysostomos2012-11-201-1/+1
| | | | | This assertion helped me to find and fix a crashing bug, so I don’t want it to be removed.