This file contains the functions that create and manipulate scratchpads, which are array-of-array data structures attached to a CV (ie a sub) and which store lexical variables and opcode temporary and per-thread values.
For these purposes "forms" are a kind-of CV, eval""s are too (except they're not callable at will and are always thrown away after the eval"" is done executing). Require'd files are simply evals without any outer lexical scope.
XSUBs don't have CvPADLIST set - dXSTARG fetches values from PL_curpad, but that is really the callers pad (a slot of which is allocated by every entersub).
The CvPADLIST AV has does not have AvREAL set, so REFCNT of component items is managed "manual" (mostly in pad.c) rather than normal av.c rules. The items in the AV are not SVs as for a normal AV, but other AVs:
0'th Entry of the CvPADLIST is an AV which represents the "names" or rather the "static type information" for lexicals.
The CvDEPTH'th entry of CvPADLIST AV is an AV which is the stack frame at that depth of recursion into the CV. The 0'th slot of a frame AV is an AV which is @_. other entries are storage for variables and op targets.
During compilation: PL_comppad_name is set to the names AV. PL_comppad is set to the frame AV for the frame CvDEPTH == 1. PL_curpad is set to the body of the frame AV (i.e. AvARRAY(PL_comppad)).
PL_comppad_name
PL_comppad
PL_curpad
During execution, PL_comppad and PL_curpad refer to the live frame of the currently executing sub.
Iterating over the names AV iterates over all possible pad items. Pad slots that are SVs_PADTMP (targets/GVs/constants) end up having &PL_sv_undef "names" (see pad_alloc()).
Only my/our variable (SVs_PADMY/SVs_PADOUR) slots get valid names. The rest are op targets/GVs/constants which are statically allocated or resolved at compile time. These don't have names by which they can be looked up from Perl code at run time through eval"" like my/our variables can be. Since they can't be looked up by "name" but only by their index allocated at compile time (which is usually in PL_op->op_targ), wasting a name SV for them doesn't make sense.
The SVs in the names AV have their PV being the name of the variable. xlow+1..xhigh inclusive in the NV union is a range of cop_seq numbers for which the name is valid. For typed lexicals name SV is SVt_PVMG and SvSTASH points at the type. For our lexicals, the type is also SVt_PVMG, with the SvOURSTASH slot pointing at the stash of the associated global (so that duplicate our declarations in the same package can be detected). SvUVX is sometimes hijacked to store the generation number during compilation.
our
If SvFAKE is set on the name SV, then that slot in the frame AV is a REFCNT'ed reference to a lexical from "outside". In this case, the name SV does not use xlow and xhigh to store a cop_seq range, since it is in scope throughout. Instead xhigh stores some flags containing info about the real lexical (is it declared in an anon, and is it capable of being instantiated multiple times?), and for fake ANONs, xlow contains the index within the parent's pad where the lexical's value is stored, to make cloning quicker.
If the 'name' is '&' the corresponding entry in frame AV is a CV representing a possible closure. (SvFAKE and name of '&' is not a meaningful combination currently but could become so if my sub foo {} is implemented.)
my sub foo {}
Note that formats are treated as anon subs, and are cloned each time write is called (if necessary).
The flag SVf_PADSTALE is cleared on lexicals each time the my() is executed, and set on scope exit. This allows the 'Variable $x is not available' warning to be generated in evals, such as
{ my $x = 1; sub f { eval '$x'} } f();
For state vars, SVf_PADSTALE is overloaded to mean 'not yet initialised'
Create a new compiling padlist, saving and updating the various global vars at the same time as creating the pad itself. The following flags can be OR'ed together:
padnew_CLONE this pad is for a cloned CV padnew_SAVE save old globals padnew_SAVESUB also save extra stuff for start of sub
Free the padlist associated with a CV. If parts of it happen to be current, we null the relevant PL_*pad* global vars so that we don't have any dangling references left. We also repoint the CvOUTSIDE of any about-to-be-orphaned inner subs to the outer of this cv.
(This function should really be called pad_free, but the name was already taken)
Create a new name and associated PADMY SV in the current pad; return the offset. If ourgv is valid, it's an our lexical, set the SvOURGV to that value
ourgv
If fake, it means we're cloning an existing entry
Allocate a new my or tmp pad entry. For a my, simply push a null SV onto the end of PL_comppad, but for a tmp, scan the pad from PL_padix upwards for a slot which has no name and no active value.
Add an anon code entry to the current compiling pad
Check for duplicate declarations: report any of: * a my in the current scope with the same name; * an our (anywhere in the pad) with the same name and the same stash as ourstash is_our indicates that the name to check is an 'our' declaration
ourstash
is_our
Given a lexical name, try to find its offset, first in the current pad, or failing that, in the pads of any lexically enclosing subs (including the complications introduced by eval). If the name is found in an outer pad, then a fake entry is added to the current pad. Returns the offset in the current pad, or NOT_IN_PAD on failure.
Find a named lexical anywhere in a chain of nested pads. Add fake entries in the inner pads if it's found in an outer one.
Returns the offset in the bottom pad of the lex or the fake lex. cv is the CV in which to start the search, and seq is the current cop_seq to match against. If warn is true, print appropriate warnings. The out_* vars return values, and so are pointers to where the returned values should be stored. out_capture, if non-null, requests that the innermost instance of the lexical is captured; out_name_sv is set to the innermost matched namesv or fake namesv; out_flags returns the flags normally associated with the IVX field of a fake namesv.
Note that pad_findlex() is recursive; it recurses up the chain of CVs, then comes back down, adding fake entries as it goes. It has to be this way because fake namesvs in anon protoypes have to store in xlow the index into the parent pad.
Get the value at offset po in the current pad. Use macro PAD_SV instead of calling this function directly.
Set the entry at offset po in the current pad to sv. Use the macro PAD_SETSV() rather than calling this function directly.
Update the pad compilation state variables on entry to a new block
"Introduce" my variables to visible status.
Cleanup at end of scope during compilation: set the max seq number for lexicals in this scope and warn of any lexicals that never got introduced.
Abandon the tmp in the current pad at offset po and replace with a new one.
Mark all the current temporaries for reuse
Tidy up a pad after we've finished compiling it: * remove most stuff from the pads of anonsub prototypes; * give it a @_; * mark tmps as such.
Free the SV at offset po in the current pad.
Dump the contents of a padlist
dump the contents of a CV
Clone a CV: make a new CV which points to the same code etc, but which has a newly-created pad built by copying the prototype pad and capturing any outer lexicals.
Push a new pad frame onto the padlist, unless there's already a pad at this depth, in which case don't bother creating a new one. Then give the new pad an @_ in slot zero.
To install kurila, copy and paste the appropriate command in to your terminal.
cpanm
cpanm kurila
CPAN shell
perl -MCPAN -e shell install kurila
For more information on module installation, please visit the detailed CPAN module installation guide.