summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [perl #87708] Fix ‘$tied binop $tied’Father Chrysostomos2011-04-073-31/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The short story: In 5.13.1 or .2 these ops started calling get-magic just once if the same gmagical scalar was used for both operands. Then the same value would be used on both sides. In 5.12 FETCH would be called twice with both return values used, but they would be swapped in most cases (so $t/$t would return 1.5 if $t returned 2 and then 3). Now FETCH is called twice and the two operands are used in the right order. Up till now there have been patches to fix specific ops, but I real- ised that the same ten or so lines of code would have to be added to the rest of the 20+ pp_ functions, all of which use tryAMAGICbin_MG (which calls Perl_try_amagic_bin in gv.c), so it made sense to add the code to Perl_try_amagic_bin instead. This fixes all the ops in one fell swoop. The code in question checks whether the left and right operands are the same gmagical scalar. If so, it copies the scalar into a new mor- tal one, and then calls get-magic on the original operand to get its new value (for the rhs). The new scalar is placed just below the top of the stack, so it becomes the left operand. This does slow down the bitwise integer ops slightly, but only in this rare edge case. And the simplification of the code seems worth it. Forthcoming are commits that revert some of the changes already made, as this commit renders them unnecessary.
* [perl #87708] $tied == $tiedFather Chrysostomos2011-04-073-7/+21
| | | | | | | | | | | | | | | | | | This is only part of #87708. This fixes the + operator outside of any ‘use integer’ scope when the same tied scalar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x it just worked. I tried modifying pp_eq throughout to take this case into account, but it made the most common cases slightly slower, presumably because of the extra checks. So this follows the same temp sv method that I used for pp_add (in 4c3ac4b and 837c879), which, though slowing down this edge cases due to the extra allocation, leaves the most common cases just as fast. (And, in case my benchmarks were unreliably [not unlikely], this method is also safer, as it has less chance of getting different code paths wrong.)
* Make :utf8 and :bytes MULTIARGLeon Timmermans2011-04-071-2/+2
| | | | | | | | | | | | | | | | PerlIO layer types have this property that flags if they can accept multiple arguments or only one. Unfortunately, this always checks the uppermost layer that has an Open method defined. This causes issues when used with utf8 or bytes on top of a layer that uses multiple arguments. For 5.15 I think abolishing this feature may make most sense. It's just flat out wrong IMO, it's the layer that uses the arguments that should validate them, not the topmost, which may not even touch them. In the mean time adding the multiargs flag to :utf8 and :bytes is a reasonable stop-gap. This patch makes perl slightly more permissive, so it shouldn't break any working code out there.
* PATCH: [perl #87810] BBC Text::MultiMarkdownKarl Williamson2011-04-071-1/+1
| | | | | | | | | | A statement should have been outside a block but was inside it. The indentation was correct, and in a number of times reading the code I still missed it. I'm having trouble distilling down the failure scenario into a simple test case, and am short on tuits right now, so a test will be committed later.
* [perl #87388] bless[], "main::" crashesFather Chrysostomos2011-04-062-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mention in the ticket, this was caused by b4dd662, which removed ‘dead’ code from gv_stashpvn: commit b4dd66232df8f0d1c00796970dec7fc37fbe9edf Author: Nicholas Clark <nick@ccl4.org> Date: Fri Oct 8 21:33:29 2010 +0100 Remove dead code from Perl_gv_stashpvn(). GvHV() and HvNAME() will both always already be set, as gv_fetchpvn_flags() will initialise these as it walks the string in its initial loop to locate the correct stash, then return early because name == name_end. This code has been dead since it was added in 5.000. --- a/gv.c +++ b/gv.c @@ -927,11 +927,9 @@ Perl_gv_stashpvn(pTHX_ const char *name, U32 namelen, I32 flags) Safefree(tmpbuf); if (!tmpgv) return NULL; - if (!GvHV(tmpgv)) - GvHV(tmpgv) = newHV(); stash = GvHV(tmpgv); - if (!HvNAME_get(stash)) - hv_name_set(stash, name, namelen, 0); + assert(stash); + assert(HvNAME_get(stash)); return stash; } This routine, before the snippet shown, adds two colons to the end of the name and then passes "main::::" to gv_fetch_pvn_flags. gv_fetch_pvn_flags, when it parses a "::", sets the next subname to point to the character after the second colon, and then continues scanning from the next character *after* that. So foo::::bar becomes $foo::{"::bar"} and main:::: becomes $main::{"::"}. The code that assigns the name to the stash and the early exit are both inside an if(we have a package separator) block, but the final :: is not considered one, so a nameless hash is returned. The easiest way to fix this is to revert just the changes to lines that deal with the name (since the other deleted lines are really dead).
* Correct stupidities in 4c3ac4bFather Chrysostomos2011-04-062-2/+7
| | | | | | | Allocating an extra SV for rare edge cases...er...only needs to be done in those rare edge cases. Uninitialized warnings are only supposed to be enabled when they are.
* [perl #87708] $tied + $tiedFather Chrysostomos2011-04-063-1/+21
| | | | | | | | | This is just part of #87708. This fixes the + operator outside of any ‘use integer’ when the same tied scalar is used for both operands and returns two different val- ues. Before this commit, get-magic would be called only once and the same value used. In 5.12.x it worked.
* make mg_clear() et al behave when RC==0David Mitchell2011-04-071-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | The functions S_save_magic() and S_restore_magic(), which are called by mg_get(), mg_set(), mg_length(), mg_size() and mg_clear(), are not robust when called with an SV whose reference count is zero. Basically, one of the actions of S_save_magic() is to temporarily increase the refcount of the SV, and then for S_restore_magic() to reduce it again at the end, so that if any of the magic functions called inbetween decrease the count, it won't be prematurely freed. However, if the count starts at zero, then bumping it up and bringing it back down to zero, triggers a spurious second freeing. So, if its zero, just skip the whole bumping thing. Now, we shouldn't really be calling these functions will a zero-refcount SV, but these things happen, and its best to be robust. In particular, this fixes RT #87860, which was ultimately triggered by a bug in Set::Object 1.28 that managed to create an HV with null SvMAGIC field, but with the RMG flag set. When freeing that HV, sv_clear() skips doing mg_free() because SvMAGIC is null, whereas later it calls Perl_hv_undef_flags, which calls mg_clear() because it uses the test SvRMAGICAL(hv) (which is true).
* [perl #87708] $tied / $tied under use integerFather Chrysostomos2011-04-063-7/+4
| | | | | | | | | This is just part of #87708. This fixes the / operator under ‘use integer’ when the same tied sca- lar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x the operands were swapped.
* [perl #87708] $tied % $tied and $tied * $tied under use integerFather Chrysostomos2011-04-064-15/+14
| | | | | | | | | | | | | | | | | This is just part of #87708. This fixes the % and * operators under ‘use integer’ when the same tied scalar is used for both operands and returns two different val- ues. Before this commit, get-magic would be called only once and the same value used. In 5.12.x * just worked but the operands were swapped for %. It turns out that every operator using the dPOPTOPiirl_nomg macro needs exactly the same treatment, so this commit eliminates the dPOPTOPiirl_halfmg macro added a few commits ago and modifies dPOPTOPiirl_nomg to do was it was doing. This should be perfectly safe, as dPOPTOPiirl_nomg has not been in a stable release (and is only for internal use anyway).
* [perl #87708] $tied + $tied and $tied - $tied under ‘use integer’Father Chrysostomos2011-04-063-17/+7
| | | | | | | | | This is just part of #87708. This fixes + and - under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x + just worked but the operands were swapped for -.
* [perl #87708] use integer; $tied < $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes < under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x the operands were swapped.
* [perl #87708] use integer; $tied > $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes > under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x the operands were swapped.
* [perl #87708] use integer; $tied <= $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes <= under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this com- mit, get-magic would be called only once and the same value used. In 5.12.x the operands were swapped.
* [perl #87708] use integer; $tied >= $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes >= under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this com- mit, get-magic would be called only once and the same value used. In 5.12.x the operands were swapped.
* [perl #87708] use integer; $tied == $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes == under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this com- mit, get-magic would be called only once and the same value used. In 5.12.x it just worked.
* [perl #87708] use integer; $tied != $tiedFather Chrysostomos2011-04-063-3/+3
| | | | | | | | | This is just part of #87708. This fixes != under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this com- mit, get-magic would be called only once and the same value used. In 5.12.x it just worked.
* PATCH: [perl #87908] \W is its complement sometimesKarl Williamson2011-04-061-1/+1
| | | | | | | | | | A missing '!' turned \W into \w in some code execution paths and utf8 data. This patch fixes that. It does not include tests at the moment, since I don't have time just now to examine why the existing tests didn't catch this, when it looks like they are set up to, and there have been several BBC tickets lately that I'm hopeful this may fix and head off other ones.
* [perl #87708] use integer; $tied <=> $tiedFather Chrysostomos2011-04-064-3/+8
| | | | | | | | | This is just part of #87708. This fixes <=> under ‘use integer’ when the same tied scalar is used for both operands and returns two different values. Before this com- mit, get-magic would be called only once and the same value used. In 5.12.x, the operands would be reversed.
* c31c2913 swaps the order of uninitialised warnings, so update test expectationsNicholas Clark2011-04-061-1/+1
|
* [perl #87708] atan2 $tied, $tiedFather Chrysostomos2011-04-053-4/+9
| | | | | | | This fixes atan2 when the same tied scalar is used for both operands and returns two different values. Before this commit, get-magic would be called only once and the same value used. In 5.12.x, the operands would be reversed.
* PATCH: [perl #87726] unwanted warning from diagnostics.pm under -wKarl Williamson2011-04-051-1/+1
| | | | It turns out to be an extra semicolon
* Er, 87708, not 87726Father Chrysostomos2011-04-051-1/+1
|
* TODO tests for [perl #87726]Father Chrysostomos2011-04-051-5/+100
|
* In Darwin's hints, only add -no-cpp-precomp to ccflags if it's not an error.Nicholas Clark2011-04-051-4/+6
| | | | | | | | | | | Previously -no-cpp-precomp was added uncondtionally to cppflags and ccflags. Apple's compiler accepts this unconditionally. gcc 4.5 warns about it, but ignores it. gcc 4.6 treats the unknown flag as an error. Hence test whether the flag causes problems, and only add it if it does not. (Searching with Google suggests that this flag has been unnecessary on OS X for some time. However, there's no clear documentation about it to confirm when it stopped being necessary.)
* Bump ExtUtils::CBuilder version following a24b897525551a1d.Nicholas Clark2011-04-0514-14/+14
|
* perldelta entry for the [perl #87664] fixFather Chrysostomos2011-04-041-0/+11
|
* perldelta: File::Basename’s versionFather Chrysostomos2011-04-041-1/+1
|
* Revert "Remove MacOS classic support from File::Basename."Father Chrysostomos2011-04-042-5/+47
| | | | | | This reverts commit e713b73750eb9e684a6d14dcca1a22d55ce2226d. See [perl #87704].
* Make ExtUtils::CBuilder reset ccflags on compile for VMS.Craig A. Berry2011-04-041-0/+15
| | | | | | | | | | | | | | | | | | | | On VMS only, the /DEFINE and /INCLUDE qualifiers are parsed off the local copy of $Config{ccflags} and consumed in the process. This is necessary because you're only allowed one of each of these clauses in the compile command, so to add whatever has been requested for a specific compile, we have to combine them with whatever Perl was built with. But since they are consumed, multiple compiles on the same EU::CB object were only using the correct flags for the first one. Even calling the have_compiler() check before compile() would make the latter miss the defines and includes that were used to build Perl. The solution is add a platform override that resets the local copy of $Config{ccflags} from its original in %Config every time a compiler operation is initiated. Fixes smoke failures in ExtUtils::ParseXS.
* [perl #87664] Don’t autovivify stashes when anonymising CVsFather Chrysostomos2011-04-032-2/+16
| | | | | | | | | | | | | | | | | | | | | | | This commit stops CV anonymisation from autovivifying stashes to point to (unless the stash is %__ANON__::). If a stash has been deleted from its original position in the symbol table, then its HvNAME will no longer indicate where to find it. S_anonymise_cv_maybe in sv.c was using the HvNAME to look up (and autovivify) the *__ANON__ glob in the stash, without taking into account that it might not actually be looking in the right spot. So now, after checking that the stash still has a name (HvNAME), it uses the HvENAME to find it. If the HvENAME is null, which indicates that the stash has been detached altogether, then %__ANON__:: is used, as happens when HvNAME is null. This solves a Class::Monadic failure introduced by commit 2d0d1eccfc ([perl #79208] %stash:: = () anonymises CVs), which was included in 5.13.7. Basically, it can be reduced to this:
* [perl #87064] eval no longer shares filtersFather Chrysostomos2011-04-038-7/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit: commit f07ec6dd59215a56bc1159449a9631be7a02a94d Author: Zefram <zefram@fysh.org> Date: Wed Oct 13 19:05:19 2010 +0100 remove filter inheritance option from lex_start The only uses of lex_start that had the new_filter parameter false, to make the new lexer context share source filters with the previous lexer context, were uses with rsfp null, which therefore never invoked source filters. Inheriting source filters from a logically unrelated file seems like a silly idea anyway. string evals could inherit the same source filter space as the cur- rently compiling code. Despite what the quoted commit message says, sharing source filters allows filters to be inherited in both direc- tions: A source filter created when the eval is being compiled also applies to the file with which it is sharing its space. There are at least 20 CPAN distributions relying on this behaviour (or, rather, what could be considered a Test::More bug). So this com- mit restores the source-filter-sharing capability. It does not change the current API or make public the API for sharing source filters, as this is supposed to be a temporary stop-gap measure for 5.14.
* Make Changes refer to the upcoming release for the full changelogFlorian Ragwitz2011-04-021-2/+2
|
* Add a note to the RMG about the fact that you should run tests afterJesse Vincent2011-04-021-0/+8
| | | | bumping the perl version
* Manually change the sha that uconfig.h was generated from. Something inJesse Vincent2011-04-021-1/+1
| | | | | | | | | | the auto-regen magic isn't doing the right thing for uperl. We should either be skipping the regen check on it or we should be automating it. t/porting/regen.t failed without this change. We should also consider making bump-perl-version NOT operate on any generated files and mandate a rerun after bumping versions
* Added a 5.14 feature bundle (identical to the 5.13 feature bundle)Jesse Vincent2011-04-021-1/+2
|
* First provisional bump to 5.14.0-RC0Jesse Vincent2011-04-0226-209/+210
|
* We shouldn't be changing perl version numbers in blead-isn't-upstreamJesse Vincent2011-04-021-0/+1
| | | | CPAN modules
* Remove a semi-erroneous misleading perldelta entryFather Chrysostomos2011-04-011-4/+0
| | | | I misread a commit message. I should have tried it out. :-)
* perlrequick: /o no longer neededKarl Williamson2011-04-011-16/+1
| | | | This is wrong, and doesn't belong in an introductory document
* perlrequick: Capitalize Perl when used as a nounKarl Williamson2011-04-011-7/+7
| | | | This is for consistency with other pods
* perlreref: Fix column in tableKarl Williamson2011-04-011-1/+1
|
* perlreref: Update for 5.14 changesKarl Williamson2011-04-011-3/+9
|
* Update HTTP::Tiny’s version in perldeltaFather Chrysostomos2011-04-011-1/+1
|
* Update HTTP::Tiny to CPAN version 0.012David Golden2011-04-012-3/+6
| | | | | | | | | | | | | | | | | | | HTTP::Tiny 0.011 fails to mirror files correctly on MSWin32, preventing CPAN bootstrapping over HTTP with just core Perl. This is fixed in CPAN version 0.012. [DELTA] 0.012 2011-03-31 15:48:02 America/New_York [BUG FIXES] - mirror() now uses binmode during output (RT #67118) [Serguei Trouchelle] [DOCUMENTATION] - noted that SSL certificates are not verified against CA's (RT #66907)
* perldelta: uc/lc(first) fix [perl #87336]Father Chrysostomos2011-03-311-0/+6
|
* perlretut: /o no longer very usefulKarl Williamson2011-03-311-33/+9
| | | | | perlretut still says /o is needed to prevent regex re-compilation in loops.
* perlretut: Remove references to Unicode blocksKarl Williamson2011-03-311-4/+1
| | | | | | | blocks are mostly useless, and not suitable for an introduction to regular expressions. It was not always the case, as in very early Unicode these were the best approximation to the much more useful Script concept. But that changed 10 or so years ago.
* perlretut: nitsKarl Williamson2011-03-311-5/+8
|
* perlretut: Emphasize difference of /rKarl Williamson2011-03-311-1/+2
|
View Lorry Controller Status