Make a dummy OPpPAD_STATE and a dummy PL_unitcheck_save available to
[p5sagit/p5-mst-13.2.git] / pod / perlintern.pod
index 2cc6868..83bdda3 100644 (file)
@@ -1,3 +1,9 @@
+-*- buffer-read-only: t -*-
+
+!!!!!!!   DO NOT EDIT THIS FILE   !!!!!!!
+This file is built by autodoc.pl extracting documentation from the C source
+files.
+
 =head1 NAME
 
 perlintern - autogenerated documentation of purely B<internal>
@@ -136,7 +142,7 @@ Found in file pad.h
 X<PAD_COMPNAME_GEN>
 
 The generation number of the name at offset C<po> in the current
-compiling pad (lvalue). Note that C<SvCUR> is hijacked for this purpose.
+compiling pad (lvalue). Note that C<SvUVX> is hijacked for this purpose.
 
        STRLEN  PAD_COMPNAME_GEN(PADOFFSET po)
 
@@ -147,7 +153,7 @@ Found in file pad.h
 X<PAD_COMPNAME_GEN_set>
 
 Sets the generation number of the name at offset C<po> in the current
-ling pad (lvalue) to C<gen>.  Note that C<SvCUR_set> is hijacked for this purpose.
+ling pad (lvalue) to C<gen>.  Note that C<SvUV_set> is hijacked for this purpose.
 
        STRLEN  PAD_COMPNAME_GEN_set(PADOFFSET po, int gen)
 
@@ -470,6 +476,48 @@ Found in file gv.c
 
 =back
 
+=head1 Hash Manipulation Functions
+
+=over 8
+
+=item refcounted_he_chain_2hv
+X<refcounted_he_chain_2hv>
+
+Generates an returns a C<HV *> by walking up the tree starting at the passed
+in C<struct refcounted_he *>.
+
+       HV *    refcounted_he_chain_2hv(const struct refcounted_he *c)
+
+=for hackers
+Found in file hv.c
+
+=item refcounted_he_free
+X<refcounted_he_free>
+
+Decrements the reference count of the passed in C<struct refcounted_he *>
+by one. If the reference count reaches zero the structure's memory is freed,
+and C<refcounted_he_free> iterates onto the parent node.
+
+       void    refcounted_he_free(struct refcounted_he *he)
+
+=for hackers
+Found in file hv.c
+
+=item refcounted_he_new
+X<refcounted_he_new>
+
+Creates a new C<struct refcounted_he>. As S<key> is copied, and value is
+stored in a compact form, all references remain the property of the caller.
+The C<struct refcounted_he> is returned with a reference count of 1.
+
+       struct refcounted_he *  refcounted_he_new(struct refcounted_he *const parent, SV *const key, SV *const value)
+
+=for hackers
+Found in file hv.c
+
+
+=back
+
 =head1 IO Functions
 
 =over 8
@@ -494,6 +542,17 @@ Found in file doio.c
 
 =over 8
 
+=item magic_sethint
+X<magic_sethint>
+
+Triggered by a delete from %^H, records the key to
+C<PL_compiling.cop_hints_hash>.
+
+       int     magic_sethint(SV* sv, MAGIC* mg)
+
+=for hackers
+Found in file mg.c
+
 =item mg_localize
 X<mg_localize>
 
@@ -560,19 +619,19 @@ 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.
-NV+1..IV inclusive 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 C<our> lexicals, the type is also SVt_PVGV, with the MAGIC slot
-pointing at the stash of the associated global (so that duplicate C<our>
-declarations in the same package can be detected).  SvCUR is sometimes
-hijacked to store the generation number during compilation.
+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 C<our> lexicals, the type is also SVt_PVMG, with the
+SvOURSTASH slot pointing at the stash of the associated global (so that
+duplicate C<our> declarations in the same package can be detected).  SvUVX is
+sometimes hijacked to store the generation number during compilation.
 
 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 NVX and IVX to store a cop_seq range, since it is
-in scope throughout. Instead IVX stores some flags containing info about
+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, NVX contains the index
+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.
 
@@ -655,11 +714,11 @@ offset.
 If C<typestash> is valid, the name is for a typed lexical; set the
 name's stash to that value.
 If C<ourstash> is valid, it's an our lexical, set the name's
-OURSTASH to that value
+SvOURSTASH to that value
 
 If fake, it means we're cloning an existing entry
 
-       PADOFFSET       pad_add_name(const char *name, HV* typestash, HV* ourstash, bool clone)
+       PADOFFSET       pad_add_name(const char *name, HV* typestash, HV* ourstash, bool clone, bool state)
 
 =for hackers
 Found in file pad.c
@@ -717,7 +776,7 @@ 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 NVX the index into
+because fake namesvs in anon protoypes have to store in xlow the index into
 the parent pad.
 
        PADOFFSET       pad_findlex(const char *name, const CV* cv, U32 seq, int warn, SV** out_capture, SV** out_name_sv, int *out_flags)
@@ -993,3 +1052,6 @@ document their functions.
 
 perlguts(1), perlapi(1)
 
+=cut
+
+ ex: set ro: