summaryrefslogtreecommitdiff
path: root/pad.h
Commit message (Collapse)AuthorAgeFilesLines
* Fix a bunch of memory leaks in feature 'class'Paul "LeoNerd" Evans2023-02-171-0/+1
| | | | | | | | | | | * Free the attrlist OP fragment when applying class or field attribute * Free the OP_PADxV ops we only use to get the pad index out for fieldvar declarations * Add a refcount to the `struct padname_fieldinfo` to keep track of its capture in inner closures so it can be freed at the right time * Free the class-related fields out of HvAUX * Free the actual ObjectFIELDS() array when destroying an object instance * Dup fieldinfo->paramname at sv_dup() time / free it at free time
* Provide padname_dup_inc() and padnamelist_dup_inc()Paul "LeoNerd" Evans2023-02-131-0/+6
|
* Field :param attributes, //= and ||= default assignmentsPaul "LeoNerd" Evans2023-02-101-0/+3
|
* Accept field VAR = EXPR on field varsPaul "LeoNerd" Evans2023-02-101-0/+1
| | | | | Allows non-constant expressions with side effects. Evaluated during the constructor of each instance.
* Initial attack at basic 'class' featurePaul "LeoNerd" Evans2023-02-101-0/+20
| | | | | | | | | | | | | Adds a new experimental warning, feature, keywords and enough parsing to implement basic classes with an empty `new` constructor method. Inject a $self lexical into method bodies; populate it with the object instance, suitably shifted Creates a new OP_METHSTART opcode to perform method setup Define an aux flag to remark which stashes are classes Basic implementation of fields. Basic anonymous methods.
* Define the concept of a suspended compcvPaul "LeoNerd" Evans2023-02-101-0/+12
|
* perl.h - break up * lined comment leaders and pod commentsYves Orton2023-02-091-1/+2
| | | | | | Having half of the comment have the * on the left side is confusing for humans and especially so for programs. Split the two style into two comments.
* pad.h - reword comment to be more legibleYves Orton2022-12-301-2/+3
| | | | | | | | | | | The prevous verbiage ended the comment with the term "padnamelist *", which put the "*" right next to the end comment marker, which was a bit confusing. This wording put the * in the middle of the sentence where it is clear it is not a mistake. Also note that the previous text used tabs internally, and so this change /looks/ like it is off indent, it is not, it is lined up with the surrounding lines.
* Add a PadnameREFCNT_inc() macroPaul "LeoNerd" Evans2022-08-171-0/+4
| | | | | | | | | Implemented as a static inline function call, so that it can return the padname pointer itself. This would allow use in expressions such as ptr->field = PadnameREFCNT_inc(pn); That makes it similar to the familiar SvREFCNT_inc() macro.
* Guard the older `SvPAD*` wrappers with `#ifndef PERL_CORE`Paul "LeoNerd" Evans2022-07-051-14/+14
|
* Neaten the PADNAME flag constantsPaul "LeoNerd" Evans2022-07-051-15/+22
| | | | | | | | | | | Rename the `PADNAMEt_*` constants to `PADNAMEf_*`, as they're supposed to represent bitflags, not a type enumeration. Also updated the `B` and `B::Deparse` modules to make use of the new modern names (and avoid the old `SVpad_*` flags). Also added `PADNAMEt_*` back-compat defines, guarded by `#ifndef PERL_CORE` so as not to permit their use accidentally within perl core.
* Convert '!!' to cBOOL()Karl Williamson2022-06-141-3/+3
| | | | | | | | | | | | I believe the '!!' is somewhat obscure; I for one didn't know about it for years of programming C, and it was buggy in one compiler, which is why cBOOL was created, I believe. And it is graphically dense, and generally harder to read than the cBOOL() construct. This commit dates from before we moved to C99 where we can simply cast to (bool), and cBOOL() has been rewritten to do that. But the vast majority of code uses cBOOL(), and this commit brings the remainder of the core .[ch] files into uniformity.
* style: Detabify indentation of the C code maintained by the core.Michael G. Schwern2021-01-171-44/+44
| | | | | | | | | | | 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.
* autodoc.pl: Specify scn for single-purpose filesKarl Williamson2020-11-061-5/+0
| | | | | | | | 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.
* perlapi: Fix signature for PadnameOURSTASHKarl Williamson2020-11-021-1/+1
| | | | This takes a parameter
* Change some =head1 to apidoc_section linesKarl Williamson2020-09-041-1/+1
| | | | | apidoc_section is slightly favored over head1, as it is known only to autodoc, and can't be confused with real pod.
* pad.h: Add missing =cut to render pod correctlyKarl Williamson2020-09-011-0/+3
|
* Change pod for macros that require "literal strings"Karl Williamson2019-09-021-2/+2
| | | | | Now that Devel::PPPort has the ability to handle these, we can loosen the syntax for clarity.
* pad.h: Parameters to many functions are ptrsKarl Williamson2019-07-311-22/+22
| | | | | | The apidoc entries for 22 functions forgot that the parameters were pointers to the type. Since these are macros, this error wasn't caught until Devel::PPPort tried to generate a test case for them.
* better document macros taking literal stringsZefram2017-11-121-4/+4
| | | | | | | | | | When giving a function-style prototype for a macro taking a literal string parameter, put a string literal in place of a type for that parameter. This goofy appearance makes it obvious that this isn't really a function, and clues the reader in that the parameter can't actually be an arbitrary expression of the right type. Also change the nonsensical "NUL-terminated literal string" to "literal string" to describe these parameters. Fixes [perl #116286].
* make PADOFFSET be SSizet_tDavid Mitchell2016-09-261-7/+1
| | | | | | | | | | | | | | | Currently it's defined as U32 or U64 depending on whether pointers are 32 bit or 64-bit, which is just a long-winded way of doing typedef Size_t PADOFFSET Change it to typedef SSize_t PADOFFSET Making it signed makes it easier to handle comparisons against PADOFFSET values that can be -1, such as PL_comppad_name_floor (which will be fixed in the next commit).
* perlapi: Clarify that a literal string must end in a NULKarl Williamson2016-02-031-4/+4
| | | | Some entries already had this. For those, it standardizes the text.
* perlapi use 'UTF-8' instead of variants of thatKarl Williamson2015-09-031-1/+1
|
* Various pods: Add C<> around many typed-as-is thingsKarl Williamson2015-09-031-9/+9
| | | | Removes 'the' in front of parameter names in some instances.
* fix PAD_COMPNAME_GEN documentationDavid Mitchell2015-08-171-3/+2
| | | | The generation number is no longer stored in the SvUVX() field
* improve debugging of padlist APIDaniel Dragan2015-07-091-2/+10
| | | | | | | | | | | | | | | | | | xpadl_alloc should really be pointer to a struct with a flexible array member, but flexible array members aren't portable enough among CCs. While debugging the padlist API for memory corruption (caused by an unrelated XS module), I saw that the pointer in the first slice of xpadl_alloc pointed to an AV head of gibberish but 2nd slice was fine. This was confusing and led me to belive the memory corruption was a bad write to the array in xpadl_alloc. PadlistARRAY's POD a couple pages down mentions that index 0 is not an AV *, but the struct comments just said "pointer to beginning of array of AVs " and didnt mention index 0. Fix the comments to make it clear what xpadl_alloc is. Add a union so it is easier to analyze a crash dump/breakpoint with a C debugger, without writing new code "PADNAMELIST * pnl = PadlistNAMES(pl);" in many places and recompiling the interp with -O0, just to be able to inspect the padnamelist struct.
* make PadlistNAMES() lvalue again.David Mitchell2015-06-081-1/+1
| | | | | | | | | | | The PadlistNAMES() macro was introduced with v5.17.3-69-g86d2498. This macro happened to be lvalue-capable, although it wasn't documented as such. v5.21.6-163-g9b7476d as a side effect, broke the lvalueness, which broke Coro. This commit restores the lvalueness.
* 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 ‘Used pad name lists for pad ids’Father Chrysostomos2014-12-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8771da69db30134352181c38401c7e50753a7ee8. Pad lists need to carry IDs around with them, so that when something tries to close over a pad, it is possible to confirm that the right pad is being closed over (either the original outer pad, or a clone of it). (See the commit message of db4cf31d1, in which commit I added an ID to the padlist struct.) In 8771da69 I found that I could use the memory address of the pad’s name list (name lists are shared) and avoid the extra field. Some time after 8771da69 I realised that a pad list could be freed, and the same address reused for another pad list, so using a memory address may not be so wise. I thought it highly unlikely, though, and put it on the back burner. I have just run into that. t/comp/form_scope.t is now failing for me with test 13, added by db4cf31d1. It bisects to 3d6de2cd1 (PERL_PADNAME_MINIMAL), but that’s a red herring. Trivial changes to the script make the problem go away. And it only happens on non- debugging builds, and only on my machine. Stepping through with gdb shows that the format-cloning is following the format prototype’s out- side pointer and confirming that it is has the correct pad (yes, the memory addresses are the same), which I know it doesn’t, because I can see what the test is doing. While generation numbers can still fall afoul of the same problem, it is much less likely. Anyway, the worst thing about 8771da69 is the typo in the first word of the commit message.
* pad.h: Use PERL_PADNAME_MINIMAL by defaultFather Chrysostomos2014-12-021-1/+1
| | | | | | See <CACmk_tvkTETxz2eFc-bJfXEhWRjAexuvv4zw4Z036OJHpWfXVA@mail.gmail.com> and <20141202004047.10267.qmail@lists-nntp.develooper.com>.
* Minimise the size of padname + string bufferFather Chrysostomos2014-11-301-12/+32
| | | | | | | | | | | | | If we define the struct a little differently, we can begin the string buffer two bytes into a pointer, rather than pointer-aligned. In case some platforms can compare pointer-aligned string faster, I added a #define to allow that. But on 64-bit darwin the speed is identical either way: $ time ./miniperl -e 'eval q|my$a;|x50000 . q|eval q<my $A>|' I ran this three times in each mode, and the average of the user times differed by less than 1%.
* [perl #123223] Make PADNAME a separate typeFather Chrysostomos2014-11-301-75/+76
| | | | | | | | | | | distinct from SV. This should fix the CPAN modules that were failing when the PadnameLVALUE flag was added, because it shared the same bit as SVs_OBJECT and pad names were going through code paths not designed to handle pad names. Unfortunately, it will probably break other CPAN modules, but I think this change is for the better, as it makes both pad names and SVs sim- pler and makes pad names take less memory.
* pad.h: Mention ‘fake’ under PadnameOUTERFather Chrysostomos2014-11-301-1/+2
| | | | | | We refer to ‘fake’ entries in various places in the documentation, and we still have the word FAKE in PARENT_FAKELEX_FLAGS, so noting this should be helpful.
* pad.h: Update PadnamePV descriptionFather Chrysostomos2014-11-301-2/+2
| | | | | GVs have been using ‘constant’ pad names for a while now, since v5.21.3-188-gc2bad63.
* Make pad names always UTF8Father Chrysostomos2014-11-301-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | Prior to 5.16, pad names never used the UTF8 flag, and all non-ASCII pad names were in UTF8. Because the latter was consistently true, everything just worked anyway. In 5.16, UTF8 handling was done ‘properly’, so that non-ASCII UTF8 strings were always accompanied by the UTF8 flag. Now, it is still the case that the only non-ASCII names to make their way into pad name code are in UTF8. Since ASCII is a subset of UTF8, we effectively *always* have UTF8 pad names. So the flag handling is actually redundant. If we just assume that all pad names are UTF8 (which is true), then we don’t need to bother with the flag checking. There is actually no reason why we should have two different encodings for storing pad names. So this commit enforces what has always been the case and removes the extra code for converting between Latin-1 and UTF8. Nothing on CPAN is using the UTF8 flag with pads, so nothing should break. In fact, we never documented padadd_UTF8_NAME.
* Make PADNAMELIST a separate typeFather Chrysostomos2014-11-301-9/+30
| | | | This is in preparation for making PADNAME a separate type.
* pad.h: Don’t use pad_compname_typeFather Chrysostomos2014-11-301-1/+1
| | | | | | | We only use PAD_COMPNAME_TYPE in one place, so wrapping it in a func- tion doesn’t save us anything, and probably slows things down if anything. Furthermore, PadnameTYPE will soon become even simpler than before.
* Use PADNAME rather than SV in the sourceFather Chrysostomos2014-11-301-5/+5
| | | | | | | | | This is in preparation for making PADNAME a separate type. This commit is not perfect. What I did was temporarily make PADNAME a separate struct identical to struct sv and make whatever changes were necessary to avoid compiler warnings. In some cases I had to add tem- porary SV casts.
* Put PL_cop_seqmax++ code in one spotFather Chrysostomos2014-11-151-0/+3
|
* Add new LVALUE flag for pad namesFather Chrysostomos2014-11-131-0/+3
| | | | | This will be used to record whether a pad entry is used as an lvalue multiple times. If so, it cannot be used as a constant.
* Fix documented return type for PAD_SVPeter Martini2014-09-071-1/+1
| | | | | It should be SV *, just like PAD_SVl, since (except under DEBUGGING) it is actually the same macro.
* fix multi-evals problems in pad name list apiDaniel Dragan2014-06-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The PAD_COMPNAME api, created in dd2155a49b , originally had alot of, multi-eval problems, since av_fetch would be repeatedly called in macro expansions. Later in commit b21dc0313d , an incomplete attempt at removing multi-eval was done. Also in commit 035dab7448 added more multi-eval problems. Prior to commit dd2155a49b , the code used a seemingly random mix of av_fetch and AvARRAY, so both are ok. To fix this, replace av_fetch with func-free AvARRAY. Since existing code has lval 0 to av_fetch and unconditional deref on ret, a segv is fine to detect breakage. A #define PAD_COMPNAME_SV(po) \ ((assert(!SvMAGICAL(PL_comppad_name))),(AvARRAY(PL_comppad_name)[(po)])) shows the AV is ! magical/tied during smoke. The assert was not added for perf reasons on debugging builds. Inline funcs were not used for better compiler optimizing if PAD_COMPNAME_FLAGS_isOUR is immediatly followed by PAD_COMPNAME_OURSTASH (2 statements), as in scan_inputsymbol. Inlines are not guaranteed to be inlined all the time on all compilers in all situations, Visual C especially. Also inline is more likely to cause readding of multi-eval problems than the macro if future changes to the API put the inline func in a multi-eval macro. On VC 2003 32bit .text section of perl521.dll dropped from 0xC296F to 0xC281F bytes of machine code with this patch.
* Remove MAD.Jarkko Hietaniemi2014-06-131-2/+0
| | | | | | MAD = Misc Attribute Decoration; unmaintained attempt at preserving the Perl parse tree more faithfully so that automatic conversion to Perl 6 would have been easier.
* [perl #120670] make perl headers C++11 compatibleTony Cook2014-01-161-5/+5
|
* Consistent spaces after dots in perlintern.podFather Chrysostomos2013-12-291-6/+7
|
* pad.h: Correct PadlistMAX docsFather Chrysostomos2013-10-301-1/+3
| | | | They have been wrong since I added them.
* Skip trailing constants when searching padsFather Chrysostomos2013-07-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* pad.c: Use &PL_sv_no for const pad namesFather Chrysostomos2013-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently &PL_sv_undef as a pad name can indicate either a free slot available for use by pad_alloc or a slot used by an op target (or, under ithreads, a constant or GV). Currently pad_alloc distinguishes between free slots and unnamed slots based on whether the value in the pad has PADMY or PADTMP set. If neither is set, then the slot is free. If either is set, the slot is in use. This makes it rather difficult to distinguish between constants stored in the pad (under ithreads) and targets. The latter need to be copied when referenced, to give the impression that a new scalar is being returned by an operator each time. (So \"$a" has to return a refer- ence to a new scalar each time, but \1 should return the same one.) Also, constants are shared between recursion levels. Currently, if the value is marked READONLY or is a shared hash key scalar, it is shared. But targets can also me shared hash keys, resulting in bugs. It also makes it impossible for the same constant to be shared by mul- tiple pad slots, as freeing one const op will turn off the PADTMP flag while the other slot still uses it, making the latter appear to be free. Hence a lot of copying occurs under ithreads. (Actually, that may not be true any more since 3b1c21fabed, as freed const ops swipe their constants from the pad. But right now, a lot of copying does still happen.) Also, XS modules may want to create const ops that return the same mutable SV each time. That is currently not possible without various workarounds including custom ops and references. (See <https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.) This commit changes pad_alloc and pad_free to use &PL_sv_no for con- stants and updates other code to keep all tests passing. Subsequent commits will actually use that information to fix bugs. This will probably break PadWalker, but I think it is an acceptable trade-off. The alternative would be to make PadnamePV forever more complex than necessary, by giving it a special case for &PL_sv_no and having it return NULL. I gave PadnameLEN a special case for &PL_sv_undef, so it may appear that I have simply shifted the complexity around. But if pad names stop being SVs, then this exception will simply disappear, since the global &PL_padname_undef will have 0 in its length field.
* Used pad name lists for pad idsFather Chrysostomos2012-10-161-2/+1
| | | | | | | | | | | | | | | | | I added pad IDs so that a pad could record which pad it closes over, to avoid problems with closures closing over the wrong pad, resulting in crashes or bizarre copies. These pad IDs were shared between clones of the same pad. In commit 9ef8d56, for efficiency I made clones of the same closure share the same pad name list. It has just occurred to be that each padlist containing the same pad name list also has the same pad ID, so we can just use the pad name list itself as the ID. This makes padlists 32 bits smaller and eliminates PL_pad_generation from the interpreter struct.
* Revert "Set PL_comppad_name on sub entry"Father Chrysostomos2012-09-171-2/+1
| | | | This reverts commit d2c8bf052f5a8bb99050f6d2418d77151eb4b468.
View Lorry Controller Status