Macros should not evaluate their arguments more than once due to the
possibility of the argument being an expression with side effects.
This commit creates an inlined helper function to do the main
processing.
Create specific macros for incrementing the refcount of an AV, CV, GV or
HV, returning a typed pointer to avoid the caller needing to cast the
result. This yields neater easier-to-read code.
While not implemented here, this gives an opportunity to add an
`assert()` check on the SvTYPE of the structure being adjusted, for
extra debug checking during debugging builds.
Commit 0d564a3d013287cf0880fdc3264f30c20fe6188d added docs for
newAV_mortal, but it needed to use "apidoc_item", not plain "apidoc".
Not doing so resulted in this build time warning:
Empty pod for newAV (from av.h) at autodoc.pl line 1265.
and the resulting pod/perlapi.pod was incorrect.
Plain "apidoc" is used to begin a new entry. "apidoc_item" is for
related subsidiary functions to the main entry.
Suggestions welcome as to how to make this relationship more obvious.
Perhaps it should be renamed "apidoc_sub_item"
The consolidation of newAV with newAV_alloc_xz? included nonsensical
juxtapositions. This cleans that up, adds a bit of markup, moves the
function implementing the newAV_alloc ones to internal, as there are no
CPAN uses, and we prefer the macro interface.
This just detabifies to get rid of the mixed tab/space indentation.
Applying consistent indentation and dealing with other tabs are another issue.
Done with `expand -i`.
* vutil.* left alone, it's part of version.
* Left regen managed files alone for now.
Many of the files in perl are for one thing only, and hence their
embedded documentation will be for that one thing. By creating a hash
here of them, those files don't have to worry about what section that
documentation goes under, and so it can be completely changed without
affecting them.
This returns the number of elements in an array in a clearly named
function.
av_top_index(), av_tindex() are clearly named, but are less than ideal,
and came about because no one back then thought of this one, until now
Paul Evans did.
This makes various fixes to the text that is used to generate the
documentation. The dominant change is to add the 'n' flag to indicate
that the macro takes no arguments. A couple should have been marked
with a D (for deprecated) flag, and a couple were missing parameters,
and a couple were missing return values.
These were spotted by using Devel::PPPort on them.
This information is already in embed.fnc, and we know it compiles. Some
of this information is now out-of-date. Get rid of it.
There was one bit of information that was (apparently) wrong in
embed.fnc. The apidoc line asked that there be no usage example
generated for newXS. I added that flag to the embed.fnc entry.
These names sparked some controversy when created:
http://www.nntp.perl.org/group/perl.perl5.porters/2016/03/msg235216.html
I looked through existing code for paradigms to follow, and found some
occurrences of 'skip_foo_mg'. So this commit changes the names to be
av_top_index_skip_len_mg()
av_tindex_skip_len_mg()
This is explicit about the type of magic that is ignored, and will still
be valid if another type of magic ever gets added.
This is like av_tindex, but doesn't handle magic. I'm not documenting
it for now, in case it turns out this was not a good idea.
Inspired from an observation by Tony Cook.
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
Under ithreads, constants and GVs are stored in the pad.
When names are looked up up in a pad, the search begins at the end and
works its way toward the beginning, so that an $x declared later masks
one declared earlier.
If there are many constants at the end of the pad, which can happen
for generated code such as lib/unicore/TestProp.pl (which has about
100,000 lines and over 500,000 pad entries for constants at the
end of the file scope’s pad), it can take a long time to search
through them all.
Before commit 325e1816, constants used &PL_sv_undef ‘names’. Since
that is the default value for array elements (when viewed directly
through AvARRAY, rather than av_fetch), the pad allocation code did
not even bother storing the ‘name’ for these. So the name pad (aka
padnamelist) was not extended, leaving just 10 entries or so in the
case of lib/unicore/TestProp.pl.
Commit 325e1816 make pad constants have &PL_sv_no names, so the
name pad would be implicitly extended as a result of storing
&PL_sv_no, causing a huge slowdown in t/re/uniprops.t (which runs
lib/unicore/TestProp.pl) under threaded builds.
Now, normally the name pad *does* get extended to match the pad,
in pad_tidy, but that is skipped for string eval (and required
file scope, of course). Hence, wrapping the contents of
lib/unicore/TestProp.pl in a sub or adding ‘my $x’ to end of it will
cause the same slowdown before 325e1816.
lib/unicore/TestProp.pl just happened to be written (ok, generated) in
such a way that it ended up with a small name pad.
This commit fixes things to make them as fast as before by recording
the index of the last named variable in the pad. Anything following
that is disregarded in pad lookup and search begins with the last
named variable. (This actually does make things faster before for
subs with many trailing constants in the pad.)
This is not a complete fix. Adding ‘my $x’ to the end of a large file
like lib/unicore/TestProp.pl will make it just as slow again.
Ultimately we need another algorithm, such as a binary search.
In using the av_top() function created in a recent commit, I found
myself being confused, and thinking it meant the top element of the
array, whereas it really means the index of the top element of that
array. Since the new name has not appeared in a stable release, it can
be changed, without remorse, to include 'index' in it.
Commit eff7e72c3 (Detect incomplete caller overrides in Carp) used
this little trick for detecting a @DB::args that an overridden
caller() failed to set:
+ @args = \$i; # A sentinal, which no-one else has the address of
But there is a bug in caller(). The first time caller tries to write
to @DB::args, it calls Perl_init_dbargs first. That function checks
whether @DB::args is AvREAL, in case someone has assigned to it, and
takes appropriate measures. But caller doesn’t bother calling
Perl_init_dbargs more than once. So manually-assigned items in
@DB::args would leak, starting with the *second* call to caller.
Commit eff7e72c3 triggered that bug, resulting in a regression in
Carp, in that it started leaking. eff7e72c3 was backported to 5.12.2
with commit 97705941a4, so in both 5.12 and 5.14 Carp is affected.
This bug (the caller bug, not Carp’s triggering thereof) also affects
any caller overrides that set @DB::args themselves, if there are
alternate calls to the overridden caller and CORE::caller.
This commit fixes that by changing the if (!PL_dbargs) condition
in pp_caller to if (!PL_dbargs || AvREAL(PL_dbargs)). I.e., if
@args is either uninitialised or AvREAL then call Perl_init_dbargs.
Perl_init_dbargs also has a bug in it, that this fixes: The array not
only needs AvREAL turned off, but also AvREIFY turned on, so that
assignments to it that occur after its initialisation turn AvREAL back
on again. (In fact, Larry Wall added a comment suggesting this back
in perl 5.000.)
