Make a dummy OPpPAD_STATE and a dummy PL_unitcheck_save available to
[p5sagit/p5-mst-13.2.git] / pod / perlintern.pod
index 6c82701..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)
 
@@ -485,16 +491,6 @@ in C<struct refcounted_he *>.
 =for hackers
 Found in file hv.c
 
-=item refcounted_he_dup
-X<refcounted_he_dup>
-
-Duplicates the C<struct refcounted_he *> for a new thread.
-
-       struct refcounted_he *  refcounted_he_dup(const struct refcounted_he *const he, CLONE_PARAMS* param)
-
-=for hackers
-Found in file hv.c
-
 =item refcounted_he_free
 X<refcounted_he_free>
 
@@ -510,12 +506,11 @@ Found in file hv.c
 =item refcounted_he_new
 X<refcounted_he_new>
 
-Creates a new C<struct refcounted_he>. Assumes ownership of one reference
-to I<value>. As S<key> is copied into a shared hash key, all references remain
-the property of the caller. The C<struct refcounted_he> is returned with a
-reference count of 1.
+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 *parent, SV *key, SV *value)
+       struct refcounted_he *  refcounted_he_new(struct refcounted_he *const parent, SV *const key, SV *const value)
 
 =for hackers
 Found in file hv.c
@@ -550,7 +545,8 @@ Found in file doio.c
 =item magic_sethint
 X<magic_sethint>
 
-Triggered by a delete from %^H, records the key to C<PL_compiling.cop_hints>.
+Triggered by a delete from %^H, records the key to
+C<PL_compiling.cop_hints_hash>.
 
        int     magic_sethint(SV* sv, MAGIC* mg)
 
@@ -623,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.
 
@@ -718,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
@@ -780,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)
@@ -1056,3 +1052,6 @@ document their functions.
 
 perlguts(1), perlapi(1)
 
+=cut
+
+ ex: set ro: