summaryrefslogtreecommitdiff
path: root/dist
Commit message (Collapse)AuthorAgeFilesLines
* update Module-CoreListRicardo Signes2012-11-204-3/+89
|
* Complete ExtUtils::ParseXS/EU::Typemaps version bumpSteffen Mueller2012-11-196-5/+8
| | | | | This moves to 3.18 across the entire distribution for a new CPAN release and completes the changelog.
* fix hash order dependency bug in new Module::Corelist::deprecated_in()Yves Orton2012-11-122-2/+10
| | | | | | | | | | | | | | | | The code was doing $version= List::Util::min(keys %$versions); which introduces a hash order dependency as min() returns either the first or last (i didnt check which) of the lowest items in the list, and considers 5.011000 and 5.011 to be equivalent. Depending on the hash order it would return either one. Hash randomization revealed this bug immediately. Changing the function to use List::Util::minstr() eliminates the dependency. $version= List::Util::minstr(keys %$versions);
* Env.pm: Fix splice in list contextFather Chrysostomos2012-11-112-2/+6
| | | | | It was passing an extra argument to splice, causing splice @PATH, 0, 0 to append ":0" to the environment variable.
* Increase $Env::VERSION to 1.04Father Chrysostomos2012-11-111-1/+1
|
* Normalize VMS case handling in ExtUtils::Manifest.Craig A. Berry2012-11-111-4/+7
| | | | | Both manifind and maniread were not completely matching filesystem behavior when downcasing filenames.
* Module-CoreList updated to 2.77Chris 'BinGOs' Williams2012-11-104-6/+39
| | | | | | | - Documented decprecated_in() function - Updated with v5.16.2 data - Updated with v5.12.5 data - Updated POD to reflect included perl data
* The v5.16.2 updates had disappeared (if they were there in the first place) ↵Chris 'BinGOs' Williams2012-11-102-0/+13
| | | | reinstate
* padrange: handle @_ directlyDavid Mitchell2012-11-102-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | In a construct like my ($x,$y) = @_ the pushmark/padsv/padsv is already optimised into a single padrange op. This commit makes the OPf_SPECIAL flag on the padrange op indicate that in addition, @_ should be pushed onto the stack, skipping an additional pushmark/gv[*_]/rv2sv combination. So in total (including the earlier padrange work), the above construct goes from being 3 <0> pushmark s 4 <$> gv(*_) s 5 <1> rv2av[t3] lK/1 6 <0> pushmark sRM*/128 7 <0> padsv[$x:1,2] lRM*/LVINTRO 8 <0> padsv[$y:1,2] lRM*/LVINTRO 9 <2> aassign[t4] vKS to 3 <0> padrange[$x:1,2; $y:1,2] l*/LVINTRO,2 ->4 4 <2> aassign[t4] vKS
* add padrange opDavid Mitchell2012-11-102-6/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This single op can, in some circumstances, replace the sequence of a pushmark followed by one or more padsv/padav/padhv ops, and possibly a trailing 'list' op, but only where the targs of the pad ops form a continuous range. This is generally more efficient, but is particularly so in the case of void-context my declarations, such as: my ($a,@b); Formerly this would be executed as the following set of ops: pushmark pushes a new mark padsv[$a] pushes $a, does a SAVEt_CLEARSV padav[@b] pushes all the flattened elements (i.e. none) of @a, does a SAVEt_CLEARSV list pops the mark, and pops all stack elements except the last nextstate pops the remaining stack element It's now: padrange[$a..@b] does two SAVEt_CLEARSV's nextstate nothing needing doing to the stack Note that in the case above, this commit changes user-visible behaviour in pathological cases; in particular, it has always been possible to modify a lexical var *before* the my is executed, using goto or closure tricks. So in principle someone could tie an array, then could notice that FETCH is no longer being called, e.g. f(); my ($s, @a); # this no longer triggers two FETCHES sub f { tie @a, ...; push @a, 1,2; } But I think we can live with that. Note also that having a padrange operator will allow us shortly to have a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple individual SAVEt_CLEARSV's.
* limit number of args before formattingJesse Luehrs2012-11-071-6/+13
| | | | this makes a difference when the number of args is quite large
* fix Carp stacktraces after deleting a stashJesse Luehrs2012-11-073-7/+142
| | | | | | When a stash is deleted, caller() will return undef in the package slot for any stack level for which the deleted stash was the current package. This made Carp confused in some cases, so fix that.
* Upgrade to Thread::Queue 3.01Jerry D. Hedden2012-11-062-31/+229
|
* Lose the loose. Fix documentation typo.Paul Johnson2012-11-051-1/+1
|
* Add C define to remove taint support from perlSteffen Mueller2012-11-053-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By defining NO_TAINT_SUPPORT, all the various checks that perl does for tainting become no-ops. It's not an entirely complete change: it doesn't attempt to remove the taint-related interpreter variables, but instead virtually eliminates access to it. Why, you ask? Because it appears to speed up perl's run-time significantly by avoiding various "are we running under taint" checks and the like. This change is not in a state to go into blead yet. The actual way I implemented it might raise some (valid) objections. Basically, I replaced all uses of the global taint variables (but not PL_taint_warn!) with an extra layer of get/set macros (TAINT_get/TAINTING_get). Furthermore, the change is not complete: - PL_taint_warn would likely deserve the same treatment. - Obviously, tests fail. We have tests for -t/-T - Right now, I added a Perl warn() on startup when -t/-T are detected but the perl was not compiled support it. It might be argued that it should be silently ignored! Needs some thinking. - Code quality concerns - needs review. - Configure support required. - Needs thinking: How does this tie in with CPAN XS modules that use PL_taint and friends? It's easy to backport the new macros via PPPort, but that doesn't magically change all code out there. Might be harmless, though, because whenever you're running under NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false. Thus, the only CPAN code that SHOULD be adversely affected is code that changes taint state.
* Increase $Module::CoreList::VERSION to 2.76Father Chrysostomos2012-11-021-1/+1
|
* print deprecation information in corelistAlexandr Ciornii2012-11-024-4/+30
|
* Data::Dumper: Optimize XPUSH's to EXTEND(), PUSH,...Steffen Mueller2012-10-222-5/+6
|
* Proper skippage for sanity check in B::Deparse's core.t.Craig A. Berry2012-10-211-1/+3
| | | | | | | | The check was being skipped when PERL_CORE was not defined or if running on VMS, but the test count was not being updated, so it would be wrong and cause the test to fail in these cases. So use the standard skip facility to handle the skipping. Plus the test works fine on VMS so go ahead and run it there as well.
* Update Module::CoreList for 5.17.5Florian Ragwitz2012-10-194-4/+62
|
* Update Module-CoreList Changes fileChris 'BinGOs' Williams2012-10-121-0/+3
|
* Add v5.14.3 data to Module::CoreList and bump to 2.74Chris 'BinGOs' Williams2012-10-122-2/+16
|
* Use const repl optimisation with s///e where possibleFather Chrysostomos2012-10-112-6/+8
| | | | | | | | | | | | | | In those cases where s///e contains a single variable or a sequence that is folded to a const op, we can do away with substcont. PMf_EVAL means that there was an /e. But we don’t actually need to check that; instead we can just examine the op tree, which we have to do anyway. The op tree that s//$x/e and s//"constant"/e compile down to have a null (a do-block) containing a scope op (block with a single state- ment, as opposed to op_leave which represents multiple statements) containing a null followed by the constant or variable.
* Deparse/t/core.t: add support for lex varsDavid Mitchell2012-10-101-20/+53
| | | | | | | | Enlarge the testing regime: before, for each op it tested foo($a,$b,$c,...) now it also does foo(my $a,$b,$c,...) my ($a,$b,$c,...); foo($a,$b,$c,...)
* overhaul dist/B-Deparse/t/core.tDavid Mitchell2012-10-101-88/+565
| | | | | | | | | | | Originally, this test file just checked that CORE::foo got correctly deparsed as CORE::foo, hence the name. This commit expands it to fully test both CORE:: verses none, plus that any arguments are correctly deparsed. It tests many more keywords, and it also cross-checks against regen/keywords.pl to make sure we've tested all keywords, and with the correct strength. (There is very little of the original file left.)
* fix deparsing of select(F)David Mitchell2012-10-102-3/+21
| | | | | | | | | | | Because select doesn't have a prototype (it's really two different functions with the same name), the code that handles "first arg as filename" was skipping select(F). This meant that 'select $fh' was being deparsed as 'select *$fh'. Make select behave the same as open etc. (There's still an issue that 'select/open *$fh' is deparsed as 'select/open $fh')
* Deparse: handle system/exec prog arg,arg,,..David Mitchell2012-10-101-0/+9
| | | | | | | | | | Deparse wasn't handling the form of system and exec where the extra first arg (without comma) gave the program name. These now deparse ok, without an additional comma: system $prog $arg1,$arg2; exec $prog $arg1,$arg2;
* Deparse: grep($a) became grep($a,); ditto mapDavid Mitchell2012-10-101-1/+2
| | | | | Not fatal, but ugly,and messed up the test format I'm currently working on in core.t
* Deparse: handle some strong keywords betterDavid Mitchell2012-10-101-3/+14
| | | | | | | | | | | | | | In general, a strong keyword 'foo' will get deparsed as plain 'foo' rather than 'CORE::foo', even in the presence of a sub foo{}. However, these weren't: glob pos prototype scalar study undef This was due to them having prototypes.
* Deparse crashed on argless sort()David Mitchell2012-10-101-0/+1
| | | | | | | This would crash @a = sort; (Test will come in a separate commit)
* bignum: Suppress warnings under 5.6Father Chrysostomos2012-10-043-11/+11
| | | | | | | | 5.6 does not like it when a sub is declared with a prototype after a reference to it has been taken. 5.6 does not think lowercase module names should be exempt from reserved word warnings before ->.
* bignum overrides.t: Fix for 5.8Father Chrysostomos2012-10-041-3/+3
| | | | | | | | | | We use the ;$ prototype for testing global overrides under 5.8, as it had no _ prototype. But back then (before 5.14, in fact) ;$ did not give a function unary precedence. Comparing against 5.009004 in bigint scope is the same as comparing against 5, resulting in incorrect version checks and skips being skipped.
* bigint: Fix new oct override for older Math::BigIntFather Chrysostomos2012-10-041-2/+2
| | | | | Older versions of Math::BigInt required the input to from_oct to begin with a 0.
* bignum overrides.t: Skip some tests under 5.8Father Chrysostomos2012-10-041-12/+24
|
* Increase bignum versions to 0.31 after the preceding changeFather Chrysostomos2012-10-043-3/+3
|
* Rewrite bignum’s hex and oct overridesFather Chrysostomos2012-10-044-124/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in <https://rt.cpan.org/Ticket/Display.html?id=79915>, bigint.pm does not use any prototype when globally overriding hex. This means that map { hex } ... will stop working in completely unre- lated code if bigint happens to be loaded. (Explicit $_ will con- tinue to work.) I thought it would be a simple matter of adding the right prototype depending on perl version (and inferring $_), but the basic tests I added failed for other reasons after I fixed the prototype and $_ handling. It turns out this whole thing is a mess, so I have basically reimple- mented these two overrides. What bigint, bignum and bigrat were doing was this: In import, *CORE::GLOBAL::hex and ::oct are assigned functions that create Math::BigInt objects if the pragma is in effect. If import is passed 'hex' or 'oct', then the function assigned does not check the pragma hints, but simply creates Math::BigInt objects regardless. This means that ‘use bigrat’ stops hex() and oct() from creating objects in ‘use bigint’ scopes, and vice versa. In fact, whichever pragma is loaded last wins. Any scopes elsewhere in the program that use the same pragma will have special hex() and oct() behaviour. But the other two lowercase big* pragmata will be disabled with regard to hex and oct. Having ‘use bigint 'hex'’ override hex globally makes no sense to me. I have no qualms about changing it, as it was already broken. Any subsequent ‘use bigint;’ would turn off the global override. So now it exports hex or oct to the calling package, just like a normal mod- ule. You can now also call bigint::hex. Also, in writing tests I found that oct("20") gives me 20. Apparently this was never tested properly. I also found notes about ‘5.9.4 or later’ when the code checked $] > 5.009004. (Actually, in one place the code checked > 5.009003, so I made it match, as we use the _ prototype now, which was intro- duced in 5.9.5.) One was in the docs, so I changed it to 5.10.0, since it is not helpful to mention dev versions. The docs were also wrong to imply that ‘no bigint’ would countermand ‘use bigint 'hex'’.
* Data::Dumper: Promote dev version to stable releaseSteffen Mueller2012-10-042-3/+9
| | | | For staying in sync with CPAN.
* Bump $ExtUtils::CBuilder::VERSION and add Changes entry for prelink() fixSteve Hay2012-10-0314-13/+20
|
* Add missing Changes entries for ExtUtils-CBuilder per its README.patchingSteve Hay2012-10-031-0/+14
|
* Allow a list of symbols to export to be passed to link() when on Windows, as ↵Eric Brine2012-10-031-1/+2
| | | | on other OSes.
* Upgrade to threads::shared 1.42Jerry D. Hedden2012-10-022-86/+456
|
* Revert "Upgrade to threads::shared 1.42"Father Chrysostomos2012-10-022-428/+68
| | | | This reverts commit 34bd199a87daedeaeadd8e9ef48032c8307eaa94.
* Upgrade to threads::shared 1.42Jerry D. Hedden2012-10-022-68/+428
|
* Upgrade to threads::shared 1.42Jerry D. Hedden2012-10-013-3/+108
|
* Bump $Carp::Heavy::VERSION too to avoid test failure from 858e29b93aSteve Hay2012-09-281-1/+1
|
* bump Carp version to 1.27Tony Cook2012-09-281-1/+1
|
* Document exportable subroutines longmess() and shortmess().jkeenan2012-09-271-10/+15
| | | | Per recommendation by srezic in RT #114280.
* Increase $B::Deparse::VERSION to 1.18Father Chrysostomos2012-09-221-1/+1
|
* [perl #94490] const fold should not trigger special split " "Father Chrysostomos2012-09-221-1/+4
| | | | | | | | | | | The easiest way to fix this was to move the special handling out of the regexp engine. Now a flag is set on the split op itself for this case. A real regexp is still created, as that is the most convenient way to propagate locale settings, and it prevents the need to rework pp_split to handle a null regexp. This also means that custom regexp plugins no longer need to handle split specially (which they all do currently).
* Update Module::CoreList for v5.17.4Florian Ragwitz2012-09-194-4/+82
|
View Lorry Controller Status