summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* In makedef.pl, no longer any need to duplicate logic from perl.hsmoke-me/makedef0Nicholas Clark2011-08-222-28/+0
| | | | | | | | | | | | | | | | | PL_OP_SLAB_ALLOC, MULTIPLICITY, PERL_IMPLICIT_CONTEXT and USE_REENTRANT_API are all now correctly picked up from Config::bincompat_options(). This also removes a really subtle bug in the diagnostics, present since the logic duplication was introduced in 18c4b137c9980e71 - this code: $define{PERL_IMPLICIT_CONTEXT} ||= $define{USE_ITHREADS} || $define{MULTIPLICITY} ; will always add a key for PERL_IMPLICIT_CONTEXT in %define, hence the later use of keys %define for output to STDERR previously always used to report PERL_IMPLICIT_CONTEXT, even though the value was (usually) undef. The code later in makedef.pl uses a truth test, so is not affected by this bug.
* boot_Win32CORE needs to be XS_EXTERNAL() following commit ab1478f7146843f7.Nicholas Clark2011-08-211-1/+1
| | | | | Win32CORE.c is shipped as a C file, not built by ExtUtils::ParseXS, so needs to be manually updated to reflect the change of default in XSUB.h
* Add tests for defined(*builtin)Father Chrysostomos2011-08-211-15/+48
| | | | | | This commit tests that GVs containing built-in variables that are usu- ally created lazily pop into existence when looked at, as the fact they didn’t exist is something we want to hide.
* Make rv2gv return autovivified magic GVsFather Chrysostomos2011-08-212-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is special code in pp_rv2gv to deal with the case of built-in variables that are created on the fly. It basically pretends that they have always existed, even in rvalue context. Normally, defined(*{"foo"}) will not actually create the *foo glob, but will simply return false. defined(*{">"}), however is supposed to return true because of the $> variable; its popping into existing when looked at being an implementation detail. That is the whole pur- pose of is_gv_magical_sv in gv.c. Prior to this commit, however, defined(*{">"}) would autovivify the GV, but then return *false*! It was simply a matter of faulty logic in this part of pp_rv2gv: SV * const temp = MUTABLE_SV(gv_fetchsv(sv, 0, SVt_PVGV)); if (!temp && (!is_gv_magical_sv(sv,0) || !(sv = MUTABLE_SV(gv_fetchsv(sv, GV_ADD, SVt_PVGV))))) { RETSETUNDEF; } sv = temp; The autovivification happens in the second gv_fetchsv call. But after the new GV is assigned to sv and the condition proves false, we reach the sv = temp assignment which clobbers it.
* Make defined(${'$'}) return trueFather Chrysostomos2011-08-211-0/+1
| | | | | | | | | | Commit 0e219455 made $$ into a magical variable that is not created on startup. Usually perl pretends that built-in vars created on the fly have always existed. But commit 0e219455 did not add $$ to the list of such variables in is_gv_magical_sv. So defined ${'$'} started return- ing false.
* Remove obsolete paragraph from perlintern/is_gv_magical_svFather Chrysostomos2011-08-211-4/+0
| | | | | This paragraph, added in 2004 by commit b9b0e72c, was made obsolete in 2008 by commit 9d8f40c4.
* Add tests for unlinkFather Chrysostomos2011-08-212-0/+39
|
* Make unlink with implicit $_ work once moreFather Chrysostomos2011-08-211-1/+1
| | | | | | | | | | | I broke this with commit ea5703f4. unlink is the only op that has the OA_DEFGV flag and no scalar or file arguments. Commit ea5703f4 changed the OA_DEFGV logic in ck_fun to generate a new $_ op for the first optional parameter, instead of just the first parameter, to avoid special-casing unpack. But lists are not marked with OA_OPTIONAL. So this commit changes it to check for list parame- ters as well.
* Mention the 5.14 and 5.15 tracks.Abigail2011-08-211-2/+2
| | | | This was done for other previous tracks as well.
* Changelog/version bump for ExtUtils::ParseXSSteffen Mueller2011-08-212-3/+17
| | | | Upgrade version in Maintainers.pl.
* Make sure to strip trailing semicolons from inputmapSteffen Mueller2011-08-214-4/+17
| | | | | | | | | If we don't get that right, there may be additional semicolons in the output C code. Those will be interpreted as empty statements which is a problem for strict/old compilers which require strict separation of declarations and other code. Reported by Torsten Schoenfeld, diagnosed by Thorsten and Jan Dubois.
* Fix C++ build following commit ab1478f7146843f7.Nicholas Clark2011-08-211-1/+1
| | | | | | For C++, ab1478f7146843f7 inadvertently defined XS_INTERNAL as extern "C" static ... which C++ compilers rightfully choke on.
* Bump $ExtUtils::ParseXS::VERSION following commit 948e998797279292.Nicholas Clark2011-08-211-1/+1
|
* add the 5.15.2 epigraphRicardo Signes2011-08-211-0/+24
|
* Make the use of XS_EXTERNAL fall back to XSSteffen Mueller2011-08-211-0/+8
| | | | | | If XSUB.h/perl doesn't define the new XS_EXTERNAL macro that we use for emitting non-static XSUBs for the boot functions, we have XS_EXTERNAL just fall back to the standard XS macro.
* Perldelta for static XSUBsSteffen Mueller2011-08-211-0/+9
|
* Make XSUBs static by defaultSteffen Mueller2011-08-211-22/+15
| | | | | | | At the same time, do not include "STATIC" in XSPROTO and get rid of the XSPROTO_INTERNAL and XSPROTO_EXTERNAL macros because of that. This allows Devel::PPPort to continue doing its evil typedef'ing magic using XSPROTO.
* Exlicitly enable exporting of some XSUB symbolsSteffen Mueller2011-08-214-4/+8
| | | | | | These are used in other compilation units. The declarations there use the XS_EXTERNAL macro to indicate an non-static XSUB that is taken from another object file.
* New XS keyword: EXPORT_XSUB_SYMBOLSSteffen Mueller2011-08-213-3/+46
| | | | | | | | | | | | | | This can be used to enable/disable the exporting of XSUB symbols. Technically and at least as far as the documentation change is concerned, this change goes together with the upcoming change to XSUB.h to make not exporting the XSUB symbols the default. It's harmless if a bit useless without that. In the original plan for making XSUBs "static", there wouldn't have been a public and easy way to make XSUBs exported from XS code without resorting to manually redefining macros. But since even in just the core set of modules, simple things break, I think it's best to expose this bit of choice.
* Refactor unpack’s newDEFSVOP logic; correct prototypeFather Chrysostomos2011-08-216-32/+17
| | | | | | | | | | | | | | | | | unpack is the only op that takes an implicit $_ for its second argu- ment. (For others it’s the first.) Instead of special-casing unpack with its own ck_ routine, we can sim- ply modify the logic in ck_fun to apply OA_DEFGV to the first optional argument, not just the first argument. Currently OA_DEFGV is not set in PL_opargs[OP_UNPACK], which means the automatically-generated prototype is ($;$), instead of ($_). This commit sets the flag on the op, changes it to use ck_fun directly, and updates ck_fun and the prototype-generation code accord- ingly. I couldn’t put this in multiple commits, as the changes are interdependent.
* Correct test in defins.tFather Chrysostomos2011-08-211-2/+1
| | | | | defined(FILE) does not work. This test ‘passed’ for me, even when I broke it.
* Test unpack with no argsFather Chrysostomos2011-08-201-1/+11
| | | | to make sure subsequent commits don’t break things.
* [perl #96000] Apply standard copyright license statementDominic Hargreaves2011-08-202-31/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original authors have agreed to alter the licensing of these files, in order to remove a potentially problematic invariant title clause: From: Doug MacEachern <dougm@…..com> To: Jon Orwant <orwant@….com> Cc: Jesse Vincent <jesse@fsck.com> Subject: Re: [fwd] [perl #96000] Restrictive licensing term on pod/perlembed.pod, pod/perlmodinstall.pod Message-ID: <1dc71b53-12e2-45d3-af62-f6d169147921@ox.local> In-Reply-To: <CAJs5hDaW+k6mf_NBj-6hPyr4rGvkEjhVtXyJ8ziLXyXimcvgHA@mail.gmail.com> Any license changes to perlembed.pod are fine with me. Or just revert to the original version of the document: "Look at perlmain.c, and do something like that." ;) Best, -Doug ----- Original Message ----- > From: "Jon Orwant" <orwant@….com> > To: "Jesse Vincent" <jesse@fsck.com> > Cc: dougm@….com > Sent: Sunday, July 31, 2011 7:38:49 PM > Subject: Re: [fwd] [perl #96000] Restrictive licensing term on pod/perlembed.pod, pod/perlmodinstall.pod > > Sure, happy to relicense. > > > Jon > > > On Sun, Jul 31, 2011 at 4:03 PM, Jesse Vincent < jesse@fsck.com > > wrote: > > > Hi Doug & Jon, > > I know it's been forever since you last touched the perl core- > > It looks like the Debian folks would like us to relax the licensing > terms on docs that bear your copyrights. > > Would you be willing to relicense the contributions you made to the > two > documents listed below under the same terms as the rest of Perl? > > Thanks! > Jesse > --
* update TOC for perl5153deltaRicardo Signes2011-08-2010-15/+22
|
* create perldelta.pod for 5.12.3Ricardo Signes2011-08-203-264/+659
|
* add new release to perlhistv5.15.2Ricardo Signes2011-08-201-0/+1
|
* remove boilerplate text from perldeltaRicardo Signes2011-08-201-243/+3
|
* update perldelta for release;Ricardo Signes2011-08-201-8/+47
| | | | | | | In particular, note the addition of the coreargs opcode in perldelta We might have no need of this entry in the perl5160 delta, but for those brave enough to read 5.15.2 delta, it may be of interest.
* WIPRicardo Signes2011-08-201-0/+4
|
* Update Module::CoreList for 5.x.yRicardo Signes2011-08-202-9/+686
|
* bump version to 5.12.2 using Porting/bump-perl-versionRicardo Signes2011-08-2021-142/+142
|
* &CORE::fork()Father Chrysostomos2011-08-192-0/+3
| | | | | | | In commit 7fa5bd9b5, I not only forgot about getpwent (see commit cc131e4, in which I mistakenly called it pwent), but fork as well. Again, all this commit has to do is add it to the list of ‘ampable’ functions in gv.c. The rest already works.
* Add OPpASSIGN_CV_TO_GV to B::ConciseFather Chrysostomos2011-08-191-0/+1
|
* Add OPpDONT_INIT_GV to B::ConciseFather Chrysostomos2011-08-191-0/+1
|
* pp.c:pp_rv2gv: Skip amagic check when vivifying a globFather Chrysostomos2011-08-191-1/+1
| | | | | | | | | | Commit bb1bc619 eliminated the only case that ‘goto wasref’ is called with something that might have overloading. The only ‘goto wasref’ that remains is the autovivifying case, which cannot have any magic (since the GV has just been created). So the wasref label can be moved below the amagic check. Consider this a picoöptimisation.
* &CORE::pwent()Father Chrysostomos2011-08-192-2/+3
| | | | | | In commit 7fa5bd9b5, I forgot about pwent. All this commit has to do is add it to the list of ‘ampable’ functions in gv.c. The rest already works.
* Ignore ExtUtils::Manifest's release tests in the coreFlorian Ragwitz2011-08-191-0/+1
|
* Upgrade ExtUtils::Manifest from version 1.59 to 1.60Florian Ragwitz2011-08-193-2/+6
|
* Swap the release suckers for 5.15.3 and 5.15.4Florian Ragwitz2011-08-191-2/+2
| | | | | | Turns out I mixed things up and would've had to do two releases in one month, which is probably not a good idea. Stevan was happy to do his release a month earlier.
* perldelta for perl #97010Father Chrysostomos2011-08-181-0/+6
|
* [perl #97020] Carp (actually caller) leaking memoryFather Chrysostomos2011-08-184-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit eff7e72c3 (Detect incomplete caller overrides in Carp) used this little trick for detecting a @DB::args that an overridden caller() failed to set: + @args = \$i; # A sentinal, which no-one else has the address of But there is a bug in caller(). The first time caller tries to write to @DB::args, it calls Perl_init_dbargs first. That function checks whether @DB::args is AvREAL, in case someone has assigned to it, and takes appropriate measures. But caller doesn’t bother calling Perl_init_dbargs more than once. So manually-assigned items in @DB::args would leak, starting with the *second* call to caller. Commit eff7e72c3 triggered that bug, resulting in a regression in Carp, in that it started leaking. eff7e72c3 was backported to 5.12.2 with commit 97705941a4, so in both 5.12 and 5.14 Carp is affected. This bug (the caller bug, not Carp’s triggering thereof) also affects any caller overrides that set @DB::args themselves, if there are alternate calls to the overridden caller and CORE::caller. This commit fixes that by changing the if (!PL_dbargs) condition in pp_caller to if (!PL_dbargs || AvREAL(PL_dbargs)). I.e., if @args is either uninitialised or AvREAL then call Perl_init_dbargs. Perl_init_dbargs also has a bug in it, that this fixes: The array not only needs AvREAL turned off, but also AvREIFY turned on, so that assignments to it that occur after its initialisation turn AvREAL back on again. (In fact, Larry Wall added a comment suggesting this back in perl 5.000.)
* Update perldiag/&CORE::%s cannot be called directlyFather Chrysostomos2011-08-181-1/+1
| | | | Something I missed in commit d47dcd9c7
* Document &CORE::nullary() callsFather Chrysostomos2011-08-182-6/+10
|
* &CORE::wantarray()Father Chrysostomos2011-08-185-5/+36
| | | | | | | | This commit allows &CORE::wantarray to be called via ampersand syntax or through references. It adds a new private flag for wantarray, OPpOFFBYONE, which caller will use as well, telling wantarray (or caller) to look one call fur- ther up the call stack.
* &CORE::foo() for nullary functionsFather Chrysostomos2011-08-185-11/+226
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes nullary subs in the CORE package callable with ampersand syntax and through references--except for wantarray, which is more complicated and will have its own commit. It does this by creating an op tree like this: $ ./perl -Ilib -MO=Concise,CORE::times -e 'BEGIN{\&CORE::times}' CORE::times: 3 <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq K ->3 1 <$> coreargs(IV 310) v ->2 2 <0> tms ->3 -e syntax OK The coreargs op checks to make sure there are no arguments, for now. The 310 is the op number for times (OP_TMS). There is no nextstate op, because we want to inherit hints from the caller. The __FILE__, __LINE__ and __PACKAGE__ directives are implemented like this: $ ./perl -Ilib -MO=Concise,CORE::__FILE__ -e 'BEGIN{\&CORE::__FILE__}' CORE::__FILE__: 7 <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq K ->7 1 <$> coreargs(PV "__FILE__") v ->2 6 <2> lslice K/2 ->7 - <1> ex-list lK ->4 2 <0> pushmark s ->3 3 <$> const(IV 1) s ->4 - <1> ex-list lK ->6 4 <0> pushmark s ->5 5 <0> caller[t1] l ->6 -e syntax OK The lslice op and its children are equivalent to (caller)[1].
* Add coreargs opFather Chrysostomos2011-08-186-3/+20
| | | | &CORE::foo subs will use this operator for sorting out @_.
* rafl has accepted the burden of a maint release.Jesse Vincent2011-08-181-1/+1
|
* Dave Cross has been volunteered for a blead releaseJesse Vincent2011-08-181-2/+2
|
* Correct spelling of KaňkovskýFather Chrysostomos2011-08-171-1/+1
|
* [perl #96126] Allocate CvFILE more simplyFather Chrysostomos2011-08-178-72/+59
| | | | | | | | | | | | | | | | | | | See the thread starting at: http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/msg175161.html Instead of assuming that only Perl subs have mallocked CvFILEs and only under threads, resulting in various hackery to borrow parts of the SvPVX buffer where that assumption proves wrong, we can simply add another flag (DYNFILE) to indicate whether CvFILE is mallocked, instead of trying to use the ISXSUB flag for two purposes. This simplifies the code greatly, eliminating bug #96126 in the pro- cess (which had to do with sv_dup not knowing about the hackery that this commit removes). I removed that comment from cv_ckproto_len about CONSTSUBs doubling up the buffer field, as it is no longer relevant. But I still left the code as it is, since it’s better to do an explicit length check.
View Lorry Controller Status