summaryrefslogtreecommitdiff
path: root/gv.h
Commit message (Collapse)AuthorAgeFilesLines
* reduce cost of SvVALID()David Mitchell2016-11-131-1/+0
| | | | | | | | Now that SvVALID() no longer just checks an SV flag, but instead checks for the existence of a certain type of magic, avoid using this more expensive macro when its not really needed. Also, and an extra flag test to SvVALID() to make it fail quicker.
* eliminate SVpbm_VALID flagDavid Mitchell2016-11-121-1/+1
| | | | | | | | This flag is set on an SV to indicate that it has PERL_MAGIC_bm (fast Boyer-Moore) magic attached. Instead just directly check whether it has such magic. This frees up the 0x40000000 bit for anything except AVs and HVs
* document save_gp() and the GVf_INTRO flagTony Cook2015-12-171-0/+4
|
* Eliminate GvASSIGN_GENERATION and _set macrosDavid Mitchell2015-08-171-5/+0
| | | | | Since we no longer scan package vars with PL_generation for OPpASSIGN_COMMON* purposes, eliminate the macros used for that purpose.
* Eliminate PL_sawalias, GPf_ALIASED_SVDavid Mitchell2015-08-171-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | These two commits: v5.21.3-759-gff2a62e "Skip no-common-vars optimisation for aliases" v5.21.4-210-gc997e36 "Make list assignment respect foreach aliasing" added a run-time mechanism to detect aliased package variables, by either "*pkg = ...," or "for $pkg (...)", and used that information to enable the OPpASSIGN_COMMON mechanism at runtime for detecting common elements in a list assign, e.g. for $alias ($a, ...) { ($a,$b) = (1,$alias); } The previous commit but one changed the OPpASSIGN_COMMON mechanism such that it no longer uses PL_sawalias. So this var and the mechanism for setting it can now be removed. This commit removes: * the PL_sawalias variable * the GPf_ALIASED_SV GP flag * the SAVEt_GP_ALIASED_SV and save_aliased_sv() save type.
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | 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.
* Revert "refactor gv_add_by_type"Matthew Horsfall2015-01-201-21/+10
| | | | | | | This reverts commit 819b139db33e2022424694e381422766903d4f65. This could be repapplied for 5.23.1, with modifications or additional patches to solve the breakage discussed in RT 123580.
* refactor gv_add_by_typeDaniel Dragan2015-01-061-10/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gv_add_by_type was added in commit d5713896ec in 5.11.0 . Improve gv_add_by_type by making it return the newly created SV*, instead of the the GV *, which the caller must deref both the GV head to get svu and then deref a slice into the GP, even though it already derefed svu and GP right before, to figure out whether to call gv_add_by_type in the first place. The original version of this patch had gv_add_by_type returning a SV ** to ensure lvalue-ness but it was discovered it wasn't needed and not smart. -rename gv_add_by_type since it was removed from public api and its proto changed -remove null check since it is impossible to pass null through GvAVn(), and unlikely with gv_AVadd, null segvs reliably crash in the rare case of a problem -instead of S_gv_init_svtype and gv_add_by_type using a tree of logic/ conditional jumps in asm, use a lookup table, GPe (e=enum or entry) enums are identical to offsets into the GP struct, all of then fit under 0xFF, if the CC and CPU arch wants, CC can load the const once into a register, then use the number for the 2nd deref, then use the number again as an arg to gv_add_by_type, the low (&~0xf) or high (<<2) 2 bits in a GPe can be used for something else in the future since GPe is pointer aligned -SVt_LAST triggers "panic: sv_upgrade to unknown type", so use that value for entries of a GP which are not SV head *s and are invalid to pass as an arg -remove the tree of logic in S_gv_init_svtype, replace with a table -S_gv_init_svtype is now tail call friendly and very small -change the GV**n to be rvalues only, assigning to GV**n is probably a memory leak -fix 1 core GV**n as lvalue use -GvSVn's unusual former definition is from commit 547f15c3f9 in 2005 and DEFSV as lvalue is gone in core as of commit 414bf5ae08 from 2008 since all the GV**n macros are now rvalues, this goes too -PTRPTR2IDX and PTRSIZELOG2 could use better names -in pp_rv2av dont declare strings like that VC linker won't dedup that, and other parts of core also have "an ARRAY", perl521.dll previously had 2 "an ARRAY" and "a HASH" strings in it due to this before VC 2003 32 perl521.dll .text 0xc8813 in machine code bytes after .text 0xc8623
* gv.h: Use PERL_BITFIELD32 for the bitfieldFather Chrysostomos2014-09-231-2/+2
| | | | See <https://rt.perl.org/Ticket/Display.html?id=15667#txn-1310207>.
* gv.h: Make gp_line and gp_flags into a bitfieldFather Chrysostomos2014-09-221-2/+2
| | | | | | This reduces the allocated size on Windows, where an extra header is added to what gets allocated. See <https://rt.perl.org/Ticket/Display.html?id=15667#txn-1309657>.
* Skip no-common-vars optimisation for aliasesFather Chrysostomos2014-09-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ‘no common vars’ optimisation allows perl to copy the values straight from the rhs to the lhs in a list assignment. In ($a,$b) = ($c,$d), that means $c gets assigned to $a, then $d to $b. If the same variable occurs on both sides of the expression (($a,$b)=($b,$a)), then it is necessary to make temporary copies of the variables on the rhs, before assigning them to the left. If some variables have been aliased to others, then the common vars detection can be fooled: *x = *y; $x = 3; ($x, $z) = (1, $y); That assigns 1 to $x, and then goes to assign $y to $z, but $y is the same as $x, which has just been clobbered. So 1 gets assigned instead of 3. This commit solves this by recording in each typeglob whether the sca- lar is an alias of a scalar from elsewhere. If such a glob is encountered, then the entire expression is ‘tainted’ such that list assignments will assume there might be common vars.
* gv.h: Add a gp_flags fieldFather Chrysostomos2014-09-181-0/+3
| | | | | This is for flags that have to be shared with all GVs that have the same GP pointer.
* gv.h: Comment typoFather Chrysostomos2014-09-181-1/+1
|
* Remove GVf_IN_PADFather Chrysostomos2014-09-171-5/+4
| | | | | Nothing on CPAN uses it, but some CPAN modules use the associ- ated macros.
* Remove GV_ADDINEVALFather Chrysostomos2014-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | This flag does absolutely nothing. The use of 8 as a flag to pass to gv_fetchpv was added in this commit: commit 93233ece75d8fe98a77377e72c4d6004c5ea8691 Author: Chip Salzenberg <chip@pobox.com> Date: Tue Mar 3 04:39:49 1998 +0000 [win32] merge problematic maintpatch to op.c #77: "Eliminate double warnings under C<package;>" Files: gv.c op.c toke.c But nothing in gv.c made use of it at the time. Later it was changed into a #define in commit 0f303493c6. Subse- quently more uses were added in 77ca0c92 and f558d5af04. It still does nothing. Nothing outside the perl core references it.
* Make S_method_common use gv_stashpvn instead of copypasted cache usagesyber2014-08-201-0/+2
| | | | | | The previous commit copied the PL_stashcache handling code from S_method_common() to gv_stashpvn(), so now we can call that function directly rather than doing it ourselves.
* fix definition of GvFILEGV()David Mitchell2013-11-131-2/+3
| | | | | | | | | | | | It was: #define GvFILE(gv) (GvFILE_HEK(gv) ? HEK_KEY(GvFILE_HEK(gv)) : NULL) #define GvFILEGV(gv) (gv_fetchfile(GvFILE(gv))) which is a problem, since gv_fetchfile() doesn't accept a non-null argument. Change it so that the (cond ? foo : NULL) thing is outside gv_fetchfile(). This is all a bit academic since GvFILE_HEK should never be null, but it at least it shuts up a compiler warning.
* Reset method caches when GPs are sharedFather Chrysostomos2012-11-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new MRO stuff in 5.10 made PL_sub_generation++ mostly unnecessary, and almost all uses of it were replaced with mro_method_changed_in. There is only one problem: That doesn’t actually work properly. After glob-to-glob assignment (*foo = *bar), both globs share the same GP (glob pointer, or list of glob slots). But there is no list of GVs associated with any GP. So there is no way, given a GV whose GP is shared, to find out what other classes might need their method caches reset. sub B::b { "b" } *A::b = *B::b; @C::ISA = "A"; print C->b, "\n"; # should print "b" eval 'sub B::b { "c" }'; print C->b, "\n"; # should print "c" __END__ $ perl5.8.9 foo b c $ perl5.10.0 foo b b And it continues up to 5.16.x. If a GP is shared, then those places where mro_method_changed_in is called after the GP has been modified must do PL_sub_generation++ instead if the GP is shared, which can be detected through its refer- ence count.
* [perl #114924] Make method calls work with ::SUPER packagesFather Chrysostomos2012-09-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Perl caches SUPER methods inside packages named Foo::SUPER. But this interferes with actual method calls on those packages (SUPER->foo, foo::SUPER->foo). The first time a package is looked up, it is vivified under the name with which it is looked up. So *SUPER:: will cause that package to be called SUPER, and *main::SUPER:: will cause it to be named main::SUPER. main->SUPER::isa used to be very sensitive to the name of the main::FOO package (where the cache is kept). If it happened to be called SUPER, that call would fail. Fixing that bug (commit 3c104e59d83f) caused the CPAN module named SUPER to fail, because SUPER->foo was now being treated as a SUPER::method call. gv_fetchmeth_pvn was using the ::SUPER suffix to determine where to look for the method. The package passed to it (the ::SUPER package) was being used to look for cached methods, but the package with ::SUPER stripped off was being used for the rest of lookup. 3c104e59d83f made main->SUPER::foo work by treating SUPER as main::SUPER in that case. Mentioning *main::SUPER:: or doing a main->SUPER::foo call before loading SUPER.pm also caused it to fail, even before 3c104e59d83f. Instead of using publicly-visible packages for internal caches, we should be keeping them internal, to avoid such side effects. This commit adds a new member to the HvAUX struct, where a hash of GVs is stored, to cache super methods. I cannot simpy use a hash of CVs, because I need GvCVGEN. Using a hash of GVs allows the existing method cache code to be used. This new hash of GVs is not actually a stash, as it has no HvAUX struct (i.e., no name, no mro_meta). It doesn’t even need an @ISA entry as before (which was only used to make isa caches reset), as it shares its owner stash’s mro_meta generation numbers. In fact, the GVs inside it have their GvSTASH pointers pointing to the owner stash. In terms of memory use, it is probably the same as before. Every stash and every iterated or weakly-referenced hash is now one pointer larger than before, but every SUPER cache is smaller (no HvAUX, no *ISA + @ISA + $ISA[0] + magic). The code is a lot simpler now and uses fewer stash lookups, so it should be faster. This will break any XS code that expects the gv_fetchmeth_pvn to treat the ::SUPER suffix as magical. This behaviour was only barely docu- mented (the suffix was mentioned, but what it did was not), and is unused on CPAN.
* document some more Gv* macrosJesse Luehrs2012-06-211-0/+12
|
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* Merge multi and flags params to gv_init_*Father Chrysostomos2011-10-061-3/+5
| | | | | Since multi is a boolean (even though it’s typed as an int), there is no need to have a separate parameter. We can just use a flag bit.
* gv.c: newGVgen_flags and a flags parameter for gv_get_super_pkg.Brian Fraser2011-10-061-0/+1
|
* Remove method param from gv_autoload_*Father Chrysostomos2011-10-061-2/+7
| | | | | | | | method is a boolean flag (typed I32, but used as a boolean) added by commit 54310121b442. These new gv_autoload_* functions have a flags parameter, so there’s no reason for this extra effective bool. We can just use a flag bit.
* Remove 4 from new gv_autoload4_(sv|pvn?) functionsFather Chrysostomos2011-10-061-1/+1
| | | | | | | | | | | | The 4 was added in commit 54310121b442 (inseparable changes during 5.003/4 developement), presumably the ‘Don't look up &AUTOLOAD in @ISA when calling plain function’ part. Before that, gv_autoload had three arguments, so the 4 indicated the new version (with the method argument). Since these new functions don’t all have four arguments, and since they have a new naming convention, there is not reason for the 4.
* gv.c: Added gv_autoload4_(sv|pv|pvn)Brian Fraser2011-10-061-0/+1
|
* gv.c: Added gv_fetchmethod_(sv|pv|pvn)_flags.Brian Fraser2011-10-061-0/+1
| | | | | | In addition from taking a flags parameter, it also takes the length of the method; This will eventually make method lookup nul-clean.
* gv.c: Added gv_fetchmeth_(sv|pv|pvn)_autoload.Brian Fraser2011-10-061-1/+2
|
* Remove some _get variants of *NAMEUTF8 macros in [gh]v.hFather Chrysostomos2011-10-061-3/+2
| | | | | For macros that returns flags, the _get convention implies that there could be a _set variant some day. But we don’t do that for flags.
* gv.c: Added gv_fetchmeth_(sv|pv|pvn).Brian Fraser2011-10-061-0/+1
| | | | | I'm probably pushing this too early. Can't do the Perl-level tests because of that. TODO.
* gv.c: Added gv_init_(sv|pv|pvn), renamed gv_init_sv as gv_init_svtype.Brian Fraser2011-10-061-0/+1
| | | | | | | | | gv_init_pvn() is the same as the old gv_init(), but takes a flags parameter, which will be used for the UTF-8 cleanup. The old gv_init() is now implemeneted as a macro in gv.h. Also included is some minimal testing in XS::APItest.
* UTF-8 related macros in hv.h and gv.hBrian Fraser2011-10-061-0/+6
| | | | Groundwork for the following commits.
* Enter gv_fetchsv_nomgFather Chrysostomos2011-09-081-1/+4
| | | | | | | | | | | There are so many cases that use this incantation to get around gv_fetchsv’s calling of get-magic-- STRLEN len; const char *name = SvPV_nomg_const(sv,len); gv = gv_fetchpvn_flags(name, len, flags | SvUTF8(sv), type); --that it’s about time we had a shorthand.
* Eliminate is_gv_magical_svFather Chrysostomos2011-08-301-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This resolves perl bug #97978. Many built-in variables, like $], are actually created on the fly when first accessed. Perl likes to pretend that these variables have always existed, so it autovivifies the *] glob even in rvalue context (e.g., defined *{"]"}, close "]"). The list of variables that were autovivified was maintained separ- ately (in is_gv_magical_sv) from the code that actually creates them (gv_fetchpvn_flags). ‘Maintained’ is not actually precise: it *wasn’t* being maintained, and there were new variables that never got added to is_gv_magical_sv and one deleted variable that was never removed. There are only two pieces of code that call is_gv_magical_sv, both in pp.c: S_rv2gv (called by *{} and also the implicit *{} that functions like close() provide) and Perl_softrefxv (called by ${}, @{}, %{}). In both cases, the glob is immediately autovivified if is_gv_magical_sv returns true. So this commit eliminates the extra maintenance burden by extirpat- ing is_gv_magical_sv altogether, and replacing it with a new flag to gv_fetchpvn_flags, GvADDMG, which will autovivify a glob *if* it’s a magical one. It does make defined(*{"frobbly"}) slightly slower, in that it creates a temporary glob and then frees it when it sees nothing magical has been done with it. But this case is rare enough it should not matter. At least I got rid of the bugginess.
* Revert ‘Deprecate tie $handle without *’Father Chrysostomos2011-06-111-3/+0
| | | | | This reverts commit 7c7df8124bbdd7a0091f8ed82589548c8182f624, except for the perldiag entry, which we still need for splain’s sake.
* add GvCV_set() and GvGP_set() macros.David Mitchell2011-01-211-4/+11
| | | | | | | | and make GvCV() and GvGP() rvalue-only. This it to allow a future commit to eliminate some backref magic between GV and CVs, which will require complete control over assignment to the gp_cv slot.
* Deprecate tie $handle without *Father Chrysostomos2010-12-021-0/+3
|
* [perl #77362] Assigning glob to lvalue causes stringificationFather Chrysostomos2010-09-261-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test from t/op/gv.t was added by change 22315/4ce457a6: { # test the assignment of a GLOB to an LVALUE my $e = ''; local $SIG{__DIE__} = sub { $e = $_[0] }; my $v; sub f { $_[0] = 0; $_[0] = "a"; $_[0] = *DATA } f($v); is ($v, '*main::DATA'); my $x = <$v>; is ($x, "perl\n"); } That change was the one that made glob-to-lvalue assignment work to begin with. But this test passes in perl version *prior* to that change. This patch fixes the test and adds tests to make sure what is assigned is actually a glob, and not just a string. It also happens to fix the stringification bug. In doing so, it essen- tially ‘enables’ globs-as-PVLVs. It turns out that many different parts of the perl source don’t fully take this into account, so this patch also fixes the following to work with them (I tried to make these into separate patches, but they are so intertwined it just got too complicated): • GvIO(gv) to make readline and other I/O ops work. • Autovivification of glob slots. • tie *$pvlv • *$pvlv = undef, *$pvlv = $number, *$pvlv = $ref • Duplicating a filehandle accessed through a PVLV glob when the stringified form of the glob cannot be used to access the file handle (!) • Using a PVLV glob as a subroutine reference • Coderef assignment when the glob is no longer in the symbol table • open with a PVLV glob for the filehandle • -t and -T • Unopened file handle warnings
* fix indendation of DM_* flag definitionsDavid Mitchell2010-06-041-5/+5
|
* express DM_[GU]ID flags in terms of componentsDavid Mitchell2010-06-041-2/+2
|
* rename DM_ARRAY flag to DM_ARRAY_ISADavid Mitchell2010-06-041-1/+1
| | | | | This better represents its current role as specifically delaying magic on @ISA as opposed to a general array magic delay mechanism.
* Fix clang "incompatible operand types" error in ternary expressions.George Greer2010-05-271-1/+1
|
* PL_defoutgv isn't always a GV.David Mitchell2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | Nasty code like the following results in PL_defoutgv not pointing to a valid GV: my $x = *STDERR; select($x); $x = 1; This causes all sorts of SEGVs when PL_defoutgv is subsequently accessed, because most code assumes that it has a valid gv_gp pointer. It also turns out that PL_defoutgv is under-tested; for example, temporarily hacking pp_close to make an arg-less close() croak didn't cause any minitest failures. Add a new test file that does some basic testing of a bad PL_defoutgv, and fix all the obvious badness in accessing it. This also fixes #20727, which although ostensibly a tie bug, was due to PL_defoutgv pointing to a tiedelem scalar, and fun like that described above happening.
* Merge gv_IOadd() into gv_add_by_type().Nicholas Clark2009-08-081-0/+1
|
* Merge gv_AVadd(), gv_HVadd() and gv_SVadd() into gv_add_by_type().Nicholas Clark2009-08-081-0/+4
| | | | The "short" names become macro wrappers, and the Perl_* versions become mathoms.
* Remove GvREFCNT_inc(), which is deprecated and unused.Nicholas Clark2009-08-071-3/+0
|
* GvUNIQUE* have been defined as 0 since 2005/06/30 - high time to remove them.Nicholas Clark2009-04-131-10/+0
|
* Add a macro MUTABLE_PTR(p), which on (non-pedantic) gcc will not castNicholas Clark2008-10-271-1/+1
| | | | | | | | | | away const, returning a void *. Add MUTABLE_SV(sv) which uses this, and replace all (SV *) casts either with MUTABLE_SV(sv), or (const SV *). This probably still needs some work - assigning to SvPVX() and SvRV() is now likely to generate a casting error. The core doesn't do this. But as-is it's finding bugs that can be fixed. p4raw-id: //depot/perl@34605
* Update copyright years.Nicholas Clark2008-10-251-2/+2
| | | p4raw-id: //depot/perl@34585
* readable assertion namesReini Urban2008-06-081-17/+17
| | | | | | From: "Reini Urban" <rurban@x-ray.at> Message-ID: <6910a60806080541n4f7e1939q254797411545ebea@mail.gmail.com> p4raw-id: //depot/perl@34029
View Lorry Controller Status