summaryrefslogtreecommitdiff
path: root/intrpvar.h
Commit message (Collapse)AuthorAgeFilesLines
* Bump the perl version in various places for 5.23.3.Matthew Horsfall2015-08-201-2/+2
|
* document what PL_generation is forDavid Mitchell2015-08-171-1/+2
|
* Eliminate PL_sawalias, GPf_ALIASED_SVDavid Mitchell2015-08-171-3/+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.
* Bump version to 5.23.2Matthew Horsfall2015-07-201-2/+2
|
* patchlevel: we are now perl v5.23.1Ricardo Signes2015-06-201-2/+2
|
* bump version to v5.23.0Ricardo Signes2015-06-011-2/+2
|
* bump version to v5.22.0 with Porting/bump-perl-versionRicardo Signes2015-05-081-2/+2
|
* Bump version for 5.21.12 (although it's unlikely to happen)Steve Hay2015-04-211-2/+2
|
* Bump version for 5.21.11 (if that happens)Steve Hay2015-03-201-2/+2
|
* Skip PL_warn_locale use unless compiled inKarl Williamson2015-03-071-1/+3
| | | | | | | The use of this variable was inconsistent. It was not dup'ed on thread cloning unless LC_CTYPE is being used, but elsewhere it was. This led to segfaults on threaded builds. Now it isn't touched anywhere unless LC_CTYPE is used.
* added link to announcementSawyer X2015-02-211-2/+2
|
* Add \b{sb}Karl Williamson2015-02-191-0/+1
|
* Add qr/\b{wb}/Karl Williamson2015-02-191-0/+1
|
* Remove obsolete macros/tables for \XKarl Williamson2015-02-191-2/+0
| | | | | A previous commit changed how \X is implemented, and now we don't need these anymore.
* Add qr/\b{gcb}/Karl Williamson2015-02-191-0/+1
| | | | | | | | | | | A function implements seeing if the space between any two characters is a grapheme cluster break. Afer I wrote this, I realized that an array lookup might be a better implementation, but the deadline for v5.22 was too close to change it. I did see that my gcc optimized it down to an array lookup. This makes the implementation of \X go from being complicated to trivial.
* More bumpbing of version number to 5.21.9. Missed this yesterday.Matthew Horsfall2015-01-211-2/+2
|
* Don't raise 'poorly supported' locale warning unnecessarilyKarl Williamson2014-12-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8c6180a91de91a1194f427fc639694f43a903a78 added a warning message for when Perl determines that the program's underlying locale just switched into is poorly supported. At the time it was thought that this would be an extremely rare occurrence. However, a bug in HP-UX - B.11.00/64 causes this message to be raised for the "C" locale. A workaround was done that silenced those. However, before it got fixed, this message would occur gobs of times executing the test suite. It was raised even if the script is not locale-aware, so that the underlying locale was completely irrelevant. There is a good prospect that someone using an older Asian locale as their default would get this message inappropriately, even if they don't use locales, or switch to a supported one before using them. This commit causes the message to be raised only if it actually is relevant. When not in the scope of 'use locale', the message is stored, not raised. Upon the first locale-dependent operation within a bad locale, the saved message is raised, and the storage cleared. I was able to do this without adding extra branching to the main-line non-locale execution code. This was done by adding regnodes which get jumped to by switch statements, and refactoring some existing C tests so they exclude non-locale right off the bat. These changes would have been necessary for another locale warning that I previously agreed to implement, and which is coming a few commits from now. I do not know of any way to add tests in the test suite for this. It is in fact rare for modern locales to have these issues. The way I tested this was to temporarily change the C code so that all locales are viewed as defective, and manually note that the warnings came out where expected, and only where expected. I chose not to try to output this warning on any POSIX functions called. I believe that all that are affected are deprecated or scheduled to be deprecated anyway. And POSIX is closer to the hardware of the machine. For convenience, I also don't output the message for some zero-length pattern matches. If something is going to be matched, the message will likely very soon be raised anyway.
* Bump version number to 5.21.8Max Maischein2014-12-211-2/+2
| | | | | Add 5.21.8 in Module::CoreList Point Maintainers.pl to new version of Module::CoreList
* Add OP_MULTIDEREFDavid Mitchell2014-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This op is an optimisation for any series of one or more array or hash lookups and dereferences, where the key/index is a simple constant or package/lexical variable. If the first-level lookup is of a simple array/hash variable or scalar ref, then that is included in the op too. So all of the following are replaced with a single op: $h{foo} $a[$i] $a[5][$k][$i] $r->{$k} local $a[0][$i] exists $a[$i]{$k} delete $h{foo} while these aren't: $a[0] already handled by OP_AELEMFAST $a[$x+1] not a simple index and these are partially replaced: (expr)->[0]{$k} the bit following (expr) is replaced $h{foo}[$x+1][0] the first and third lookups are each done with a multideref op, while the $x+1 expression and middle lookup are done by existing add, aelem etc ops. Up until now, aggregate dereferencing has been very heavyweight in ops; for example, $r->[0]{$x} is compiled as: gv[*r] s rv2sv sKM/DREFAV,1 rv2av[t2] sKR/1 const[IV 0] s aelem sKM/DREFHV,2 rv2hv sKR/1 gvsv[*x] s helem vK/2 When executing this, in addition to the actual calls to av_fetch() and hv_fetch(), there is a lot of overhead of pushing SVs on and off the stack, and calling lots of little pp() functions from the runops loop (each with its potential indirect branch miss). The multideref op avoids that by running all the code in a loop in a switch statement. It makes use of the new UNOP_AUX type to hold an array of typedef union { PADOFFSET pad_offset; SV *sv; IV iv; UV uv; } UNOP_AUX_item; In something like $a[7][$i]{foo}, the GVs or pad offsets for @a and $i are stored as items in the array, along with a pointer to a const SV holding 'foo', and the UV 7 is stored directly. Along with this, some UVs are used to store a sequence of actions (several actions are squeezed into a single UV). Then the main body of pp_multideref is a big while loop round a switch, which reads actions and values from the AUX array. The two big branches in the switch are ones that are affectively unrolled (/DREFAV, rv2av, aelem) and (/DREFHV, rv2hv, helem) triplets. The other branches are various entry points that handle retrieving the different types of initial value; for example 'my %h; $h{foo}' needs to get %h from the pad, while '(expr)->{foo}' needs to pop expr off the stack. Note that there is a slight complication with /DEREF; in the example above of $r->[0]{$x}, the aelem op is actually aelem sKM/DREFHV,2 which means that the aelem, after having retrieved a (possibly undef) value from the array, is responsible for autovivifying it into a hash, ready for the next op. Similarly, the rv2sv that retrieves $r from the typeglob is responsible for autovivifying it into an AV. This action of doing the next op's work for it complicates matters somewhat. Within pp_multideref, the autovivification action is instead included as the first step of the current action. In terms of benchmarking with Porting/bench.pl, a simple lexical $a[$i][$j] shows a reduction of approx 40% in numbers of instructions executed, while $r->[0][0][0] uses 54% fewer. The speed-up for hash accesses is relatively more modest, since the actual hash lookup (i.e. hv_fetch()) is more expensive than an array lookup. A lexical $h{foo} uses 10% fewer, while $r->{foo}{bar}{baz} uses 34% fewer instructions. Overall, bench.pl --tests='/expr::(array|hash)/' ... gives: PRE POST ------ ------ Ir 100.00 145.00 Dr 100.00 165.30 Dw 100.00 175.74 COND 100.00 132.02 IND 100.00 171.11 COND_m 100.00 127.65 IND_m 100.00 203.90 with cache misses unchanged at 100%. In general, the more lookups done, the bigger the proportionate saving.
* Revert ‘Used pad name lists for pad ids’Father Chrysostomos2014-12-061-0/+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.
* Add ‘immortal’ pad name intrp varsFather Chrysostomos2014-11-301-0/+2
| | | | | These will replace the current use of &PL_sv_undef and &PL_sv_no as pad names.
* Make encoding pragma lexical in scopeKarl Williamson2014-11-201-1/+2
| | | | | | | | | | | | | | | | | | | | The encoding pragma is deprecated, but in the meantime it causes spooky action at a distance with other modules that it may be combined with. In these modules, operations such as chr(), ord(), and utf8::upgrade() will suddenly start doing the wrong thing. The documentation for 'encoding' has said to call it after loading other modules, but this may be impractical. This is especially bad with anything that auto-loads at first use, like \N{} does now for charnames. There is an issue with combining this with setting the variable ${^ENCODING} directly. The potential for conflicts has always been there, and remains. This commit introduces a shadow hidden variable, subservient to ${^ENCODING} (to preserve backwards compatibility) that has lexical scope validity. The pod for 'encoding' has been revamped to be more concise, clear, use more idiomatic English, and to speak from a modern perspective.
* Bump the perl version in various places for 5.21.7Chris 'BinGOs' Williams2014-11-211-2/+2
|
* add filename handling to xs handshakeDaniel Dragan2014-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | - this improves the error message on ABI incompatibility, per [perl #123136] - reduce the number of gv_fetchfile calls in newXS over registering many XSUBs - "v" was not stripped from PERL_API_VERSION_STRING since string "vX.XX.X\0", a typical version number is 8 bytes long, and aligned to 4/8 by most compilers in an image. A double digit maint release is extremely unlikely. - newXS_deffile saves on machine code in bootstrap functions by not passing arg filename - move newXS to where the rest of the newXS*()s live - move the "no address" panic closer to the start to get it out of the way sooner flow wise (it nothing to do with var gv or cv) - move CvANON_on to not check var name twice - change die message to use %p, more efficient on 32 ptr/64 IV platforms see ML post "about commit "util.c: fix comiler warnings"" - vars cv/xs_spp (stack pointer pointer)/xs_interp exist for inspection by a C debugger in an unoptimized build
* remove obsolete PL_apiversionDaniel Dragan2014-11-071-1/+0
| | | | | Commit 0e42d607f5 made PL_apiversion unused. Remove it to save memory in interp struct.
* Bump the perl version in various places for 5.21.6Abigail2014-10-201-2/+2
|
* [perl #122445] use magic on $DB::single etc to avoid overload issuesTony Cook2014-10-091-0/+2
| | | | | | | | | This prevents perl recursing infinitely when an overloaded object is assigned to $DB::single, $DB::trace or $DB::signal This is done by referencing their values as IVs instead of as SVs in dbstate, and by adding magic to those variables so that assignments to the scalars update the PL_DBcontrol array.
* Bump version to 5.21.5Steve Hay2014-09-201-2/+2
|
* Skip no-common-vars optimisation for aliasesFather Chrysostomos2014-09-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Allow for changing size of bracketed regex char classKarl Williamson2014-09-031-0/+1
| | | | | | | | This commit allows Perl to be compiled with a bitmap size that is larger than 256. This bitmap is used to directly look up whether a character matches or not, without having to do a binary search or hash lookup. It might improve the performance for some installations that have a lot of use of scripts that are above the Latin1 range.
* Split PL_padix into two variablesFather Chrysostomos2014-08-281-0/+1
| | | | | | | | | | | | | | | | | | | | | PL_padix keeps track of the position in the pad when pad_alloc has to start scanning for an available slot. The availability of a slot is determined differently for targets (which may reuse slots that are already targets from previous state- ments, at least when pad_reset is enabled) and constants (which may not reuse targets). Having the same index for both may require scanning the entire pad for allocating a constant or GV. t/re/uniprops.t was running far too slowly under USE_BROKEN_PAD_RESET because of this. pad_reset would reset PL_padix to point to the beginning of a pad with a few hundred thousand entries. pad_alloc would then have to scan the entire pad before adding a GV to the end. It is still too slow, even with this commit, but for other reasons. (This is just a partial fix.)
* intrpvar.h: Correct commentFather Chrysostomos2014-08-281-1/+2
| | | | | | | This description has been a little faulty for quite some time, not just because of the last few commits. Any time pad_free or pad_swipe is called, that pad slot becomes available and PL_padix is reset. So ‘max used’ is not accurate.
* Bump version number from 5.21.3 to 5.21.4Peter Martini2014-08-211-2/+2
|
* Bump version number from 5.21.2 to 5.21.3Abigail2014-07-201-2/+2
|
* Bump the perl version in various places for 5.21.2Matthew Horsfall (alh)2014-06-201-2/+2
|
* Remove MAD.Jarkko Hietaniemi2014-06-131-5/+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.
* Allow dynamic lock of LC_NUMERICKarl Williamson2014-06-051-1/+1
| | | | | | | | | | | When processing version strings, the radix character must be a dot even if we otherwise would be using some other character. vutil.c upg_version() changes to the dot, but calls sv_catpvf() which may try to change the character to something else. This commit introduces a way to lock the character to a dot around the call to sv_catpvf() vutil.c is cpan-upstream, but already blead and cpan have diverged, so this just updates the SHA of the new version
* Remove deprecated 'PL_sv_objcount'Karl Williamson2014-05-291-3/+0
| | | | This was scheduled to be removed in 5.20, but was forgotten.
* bump version to 5.21.1Ricardo Signes2014-05-271-2/+2
|
* bump version to 5.21.0Ricardo Signes2014-05-261-1/+1
|
* bump version to 5.20.0, install 5.20 perldeltaRicardo Signes2014-05-121-1/+1
|
* Bump version for 5.19.12 (not that it's expected to exist...)Steve Hay2014-04-201-1/+1
|
* Fix comments and pod that mention 5.20 erroneouslyKarl Williamson2014-04-011-1/+1
| | | | | | In certain places in the documentation, "5.20" is no longer applicable. Also, a message referred to in perldiag got reworded, but our checks did not catch that perldiag should have been updated.
* Bump to Perl version 5.19.11Aaron Crane2014-03-201-1/+1
|
* pp_tms should use a local struct tms, instead of PL_timesbuf.Nicholas Clark2014-03-011-0/+1
| | | | | | | | | | PL_timesbuf is effectively a vestige of Perl 1, and doesn't actually need to be an interpreter variable. It will be removed early in v5.21.x, but it's a good idea to refactor the code not to use it before then. A local struct tms will be on the C stack, which will be in the CPU's L1 cache, whereas the relevant part of the interpreter struct may well not be in the CPU cache at all. Therefore this change might reduce cache pressure fractionally. A local variable access should also be simpler machine code on most CPU architectures.
* move PL_defgv nearer the top of intrvar.hDavid Mitchell2014-02-271-1/+1
| | | | on the grounds that its a reasonably hot variable.
* bump to version 5.19.10 and fix the version number reference in op.cTony Cook2014-02-201-1/+1
|
* Work properly under UTF-8 LC_CTYPE localesKarl Williamson2014-01-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This large (sorry, I couldn't figure out how to meaningfully split it up) commit causes Perl to fully support LC_CTYPE operations (case changing, character classification) in UTF-8 locales. As a side effect it resolves [perl #56820]. The basics are easy, but there were a lot of details, and one troublesome edge case discussed below. What essentially happens is that when the locale is changed to a UTF-8 one, a global variable is set TRUE (FALSE when changed to a non-UTF-8 locale). Within the scope of 'use locale', this variable is checked, and if TRUE, the code that Perl uses for non-locale behavior is used instead of the code for locale behavior. Since Perl's internal representation is UTF-8, we get UTF-8 behavior for a UTF-8 locale. More work had to be done for regular expressions. There are three cases. 1) The character classes \w, [[:punct:]] needed no extra work, as the changes fall out from the base work. 2) Strings that are to be matched case-insensitively. These form EXACTFL regops (nodes). Notice that if such a string contains only characters above-Latin1 that match only themselves, that the node can be downgraded to an EXACT-only node, which presents better optimization possibilities, as we now have a fixed string known at compile time to be required to be in the target string to match. Similarly if all characters in the string match only other above-Latin1 characters case-insensitively, the node can be downgraded to a regular EXACTFU node (match, folding, using Unicode, not locale, rules). The code changes for this could be done without accepting UTF-8 locales fully, but there were edge cases which needed to be handled differently if I stopped there, so I continued on. In an EXACTFL node, all such characters are now folded at compile time (just as before this commit), while the other characters whose folds are locale-dependent are left unfolded. This means that they have to be folded at execution time based on the locale in effect at the moment. Again, this isn't a change from before. The difference is that now some of the folds that need to be done at execution time (in regexec) are potentially multi-char. Some of the code in regexec was trivial to extend to account for this because of existing infrastructure, but the part dealing with regex quantifiers, had to have more work. Also the code that joins EXACTish nodes together had to be expanded to account for the possibility of multi-character folds within locale handling. This was fairly easy, because it already has infrastructure to handle these under somewhat different circumstances. 3) In bracketed character classes, represented by ANYOF nodes, a new inversion list was created giving the characters that should be matched by this node when the runtime locale is UTF-8. The list is ignored except under that circumstance. To do this, I created a new ANYOF type which has an extra SV for the inversion list. The edge case that caused the most difficulty is folding involving the MICRO SIGN, U+00B5. It folds to the GREEK SMALL LETTER MU, as does the GREEK CAPITAL LETTER MU. The MICRO SIGN is the only 0-255 range character that folds to outside that range. The issue is that it doesn't naturally fall out that it will match the CAP MU. If we let the CAP MU fold to the samll mu at compile time (which it can because both are above-Latin1 and so the fold is the same no matter what locale is in effect), it could appear that the regnode can be downgraded away from EXACTFL to EXACTFU, but doing so would cause the MICRO SIGN to not case insensitvely match the CAP MU. This could be special cased in regcomp and regexec, but I wanted to avoid that. Instead the mktables tables are set up to include the CAP MU as a character whose presence forbids the downgrading, so the special casing is in mktables, and not in the C code.
* bump version to 5.19.9!Ricardo Signes2014-01-201-1/+1
|
* Remove PL_L1Posix_ptrsKarl Williamson2014-01-091-1/+0
| | | | | | | | | | | | This global array is no longer used, having been removed in previous commits in this series. Since it is a global, consideration need be given to possible uses of it outside the core. It has never been externally documented, and is an opaque structure whose internals have changed with every release. The functions used to access it are almost all static to regcomp.c; those few that aren't have been hidden from all but the few .c files that need to have access to them, via #if's.