CV's can have CvPADLIST(cv) set to point to a PADLIST. This is the CV's scratchpad, which stores lexical variables and opcode temporary and per-thread values.
For these purposes "formats" 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 do not have a CvPADLIST. dXSTARG fetches values from PL_curpad, but that is really the callers pad (a slot of which is allocated by every entersub). Do not get or set CvPADLIST if a CV is an XSUB (as determined by CvISXSUB()), CvPADLIST slot is reused for a different internal purpose in XSUBs.
The PADLIST has a C array where pads are stored.
The 0th entry of the PADLIST is a PADNAMELIST which represents the "names" or rather the "static type information" for lexicals. The individual elements of a PADNAMELIST are PADNAMEs. Future refactorings might stop the PADNAMELIST from being stored in the PADLIST's array, so don't rely on it. See "PadlistNAMES".
The CvDEPTH'th entry of a PADLIST is a PAD (an AV) which is the stack frame at that depth of recursion into the CV. The 0th slot of a frame AV is an AV which is @_. Other entries are storage for variables and op targets.
Iterating over the PADNAMELIST iterates over all possible pad items. Pad slots for targets (SVs_PADTMP) and GVs end up having &PL_padname_undef "names", while slots for constants have &PL_padname_const "names" (see "pad_alloc"). That &PL_padname_undef and &PL_padname_const are used is an implementation detail subject to change. To test for them, use !PadnamePV(name) and PadnamePV(name) && !PadnameLEN(name), respectively.
Only my/our variable 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"" the way 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 pad names in the PADNAMELIST have their PV holding the name of the variable. The COP_SEQ_RANGE_LOW and _HIGH fields form a range (low+1..high inclusive) of cop_seq numbers for which the name is valid. During compilation, these fields may hold the special value PERL_PADSEQ_INTRO to indicate various stages:
COP_SEQ_RANGE_LOW _HIGH----------------- -----PERL_PADSEQ_INTRO 0 variable not yet introduced:{my($xvalid-seq# PERL_PADSEQ_INTRO variable in scope:{my($x);valid-seq# valid-seq# compilation of scope complete:{my($x); .... }
When a lexical var hasn't yet been introduced, it already exists from the perspective of duplicate declarations, but not for variable lookups, e.g.
my($x,$x);# '"my" variable $x masks earlier declaration'my$x=$x;# equal to my $x = $::x;
For typed lexicals PadnameTYPE points at the type stash. For our lexicals, PadnameOURSTASH points at the stash of the associated global (so that duplicate our declarations in the same package can be detected). PadnameGEN is sometimes used to store the generation number during compilation.
If PadnameOUTER is set on the pad name, then that slot in the frame AV is a REFCNT'ed reference to a lexical from "outside". Such entries are sometimes referred to as 'fake'. In this case, the name does not use 'low' and 'high' to store a cop_seq range, since it is in scope throughout. Instead 'high' 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, 'low' 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 the PAD is a CV representing a possible closure.
Note that formats are treated as anon subs, and are cloned each time write is called (if necessary).
The flag SVs_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;subf {eval'$x'} } f();
For state vars, SVs_PADSTALE is overloaded to mean 'not yet initialised', but this internal state is stored in a separate pad entry.
During compilation, this points to the array containing the names part of the pad for the currently-compiling code.
During compilation, this points to the array containing the values part of the pad for the currently-compiling code. (At runtime a CV may have many such value arrays; at compile time just one is constructed.) At runtime, this points to the array containing the currently-relevant values for the pad for the currently-executing code.
Points directly to the body of the "PL_comppad" array. (I.e., this is PadARRAY(PL_comppad).)
Create a new padlist, updating the global variables for the currently-compiling padlist to point to the new padlist. The following flags can be OR'ed together:
padnew_CLONE this pad isfora cloned CVpadnew_SAVE save old globals on the save stackpadnew_SAVESUB also save extra stuffforstart ofsub
Clear out all the active components of a CV. This can happen either by an explicit undef &foo, or by the reference count going to zero. In the former case, we keep the CvOUTSIDE pointer, so that any anonymous children can still follow the full lexical scope chain.
When a CV has a reference count on its slab (CvSLABBED), it is responsible for making sure it is freed. (Hence, no two CVs should ever have a reference count on the same slab.) The CV only needs to reference the slab during compilation. Once it is compiled and CvROOT attached, it has finished its job, so it can forget the slab.
Allocates a place in the currently-compiling pad (via "pad_alloc" in perlapi) and then stores a name for that entry. name is adopted and becomes the name entry; it must already contain the name string. typestash and ourstash and the padadd_STATE flag gets added to name. None of the other processing of "pad_add_name_pvn" in perlapi is done. Returns the offset of the allocated pad slot.
Allocates a place in the currently-compiling pad for a named lexical variable. Stores the name and other metadata in the name part of the pad, and makes preparations to manage the variable's lexical scoping. Returns the offset of the allocated pad slot.
namepv/namelen specify the variable's name in UTF-8, including leading sigil. If typestash is non-null, the name is for a typed lexical, and this identifies the type. If ourstash is non-null, it's a lexical reference to a package variable, and this identifies the package. The following flags can be OR'ed together:
padadd_STATE variable will retain value persistentlypadadd_NO_DUP_CHECK skip checkforlexical shadowingpadadd_FIELD specifies that the lexical is a fieldfora class
Exactly like "pad_add_name_pvn", but takes a nul-terminated string instead of a string/length pair.
Exactly like "pad_add_name_pvn", but takes the name string in the form of an SV instead of a string/length pair.
Allocates a place in the currently-compiling pad, returning the offset of the allocated pad slot. No name is initially attached to the pad slot. tmptype is a set of flags indicating the kind of pad entry required, which will be set in the value SV for the allocated pad entry:
SVs_PADMY named lexical variable ("my","our","state")SVs_PADTMP unnamed temporary storeSVf_READONLY constant shared between recursion levels
SVf_READONLY has been supported here only since perl 5.20. To work with earlier versions as well, use SVf_READONLY|SVs_PADTMP. SVf_READONLY does not cause the SV in the pad slot to be marked read-only, but simply tells pad_alloc that it will be made read-only (by the caller), or at least should be treated as such.
optype should be an opcode indicating the type of operation that the pad entry is to support. This doesn't affect operational semantics, but is used for debugging.
Allocates a place in the currently-compiling pad (via "pad_alloc") for an anonymous function that is lexically scoped inside the currently-compiling function. The function func is linked into the pad, and its CvOUTSIDE link to the outer scope is weakened to avoid a reference loop.
One reference count is stolen, so you may need to do SvREFCNT_inc(func).
optype should be an opcode indicating the type of operation that the pad entry is to support. This doesn't affect operational semantics, but is used for debugging.
Check for duplicate declarations: report any of:
* a'my'in the current scopewiththe same name;* an'our'(anywhere in the pad)withthe same name and thesame stash as'ourstash'
is_our indicates that the name to check is an "our" declaration.
Given the name of a lexical variable, find its position in the currently-compiling pad. namepv/namelen specify the variable's name, including leading sigil. flags is reserved and must be zero. If it is not in the current pad but appears in the pad of any lexically enclosing scope, then a pseudo-entry for it is added in the current pad. Returns the offset in the current pad, or NOT_IN_PAD if no such lexical is in scope.
Exactly like "pad_findmy_pvn", but takes a nul-terminated string instead of a string/length pair.
Exactly like "pad_findmy_pvn", but takes the name string in the form of an SV instead of a string/length pair.
Returns the global variable $_.
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 is set to the innermost matched pad name or fake pad name; out_flags returns the flags normally associated with the PARENT_FAKELEX_FLAGS field of a fake pad name.
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 names in anon prototypes have to store in xpadn_low the index into the parent pad.
Get the value at offset po in the current (compiling or executing) pad. Use macro PAD_SV instead of calling this function directly.
Set the value at offset po in the current (compiling or executing) pad. 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. This is called during parsing at the end of each statement to make lexical variables visible to subsequent statements.
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 at the end of compilation of the code to which it belongs. Jobs performed here are: remove most stuff from the pads of anonsub prototypes; give it a @_; mark temporaries as such. type indicates the kind of subroutine:
padtidy_SUB ordinary subroutinepadtidy_SUBCLONEprototypeforlexical closurepadtidy_FORMATformat
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, making a lexical closure. proto supplies the prototype of the function: its code, pad structure, and other attributes. The prototype is combined with a capture of outer lexicals to which the code refers, which are taken from the currently-executing instance of the immediately surrounding code.
Returns an SV containing the name of the CV, mainly for use in error reporting. The CV may actually be a GV instead, in which case the returned SV holds the GV's name. Anything other than a GV or CV is treated as a string already holding the sub name, but this could change in the future.
An SV may be passed as a second argument. If so, the name will be assigned to it and it will be returned. Otherwise the returned SV will be a new mortal.
If flags has the CV_NAME_NOTQUAL bit set, then the package name will not be included. If the first argument is neither a CV nor a GV, this flag is ignored (subject to change).
For any anon CVs in the pad, change CvOUTSIDE of that CV from old_cv to new_cv if necessary. Needed when a newly-compiled CV has to be moved to a pre-existing CV struct.
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.
Duplicates a pad.
Creates a new pad name list. max is the highest index for which space is allocated.
Stores the pad name (which may be null) at the given index, freeing any existing pad name in that slot.
Fetches the pad name from the given index.
Duplicates a pad name list.
Constructs and returns a new pad name. s must be a UTF-8 string. Do not use this for pad names that point to outer lexicals. See "newPADNAMEouter".
Constructs and returns a new pad name. Only use this function for names that refer to outer lexicals. (See also "newPADNAMEpvn".) outer is the outer pad name that this one mirrors. The returned pad name has the PADNAMEf_OUTER flag already set.
Duplicates a pad name.
Implements part of the concept of a "suspended compilation CV", which can be used to pause the parser and compiler during parsing a CV in order to come back to it later on.
This function saves the current state of the subroutine under compilation (PL_compcv) into the supplied buffer. This should be used initially to create the state in the buffer, as the final thing before a LEAVE within a block.
ENTER;start_subparse(0);...suspend_compcv(&buffer);LEAVE;
Once suspended, the resume_compcv_final or resume_compcv_and_save function can later be used to continue the parsing from the point this stopped.
Resumes the parser state previously saved using the suspend_compcv function for a final time before being compiled into a full CV. This should be used within an ENTER/LEAVE scoped pair.
Resumes a buffer previously suspended by the suspend_compcv function, in a way that will be re-suspended at the end of the scope so it can be used again later. This should be used within an ENTER/LEAVE scoped pair.