Commit graph

5 commits

Author SHA1 Message Date
obache
4614638f72 Update p5-Lexical-SealRequireHints to 0.005.
version 0.005; 2011-07-25

  * bugfix: work around core bug [perl #73174] affecting Unicode swash
    loading, and apply entire workaround arrangement to 5.11.{0..5}
    where [perl #73174] exists but [perl #68590] does not

  * correct dynamic_config setting to 0

  * include META.json in distribution

  * add MYMETA.json to .cvsignore

version 0.004; 2010-11-21

  * bugfix: don't attempt to use XS version of the workaround on Win32,
    where it can't work properly due to linker restriction on access to
    core symbols

  * only define PERL_CORE for compilation on Perl versions where the
    bug workaround (and thus interference with core-private stuff)
    is actually necessary

  * in XS, use PERL_NO_GET_CONTEXT for efficiency

  * in XS, declare "PROTOTYPES: DISABLE" to prevent automatic generation
    of unintended prototypes

  * in XS, provide a reserve definition of croak, so that the Perl_croak
    circumlocution is avoided even with PERL_CORE defined

  * in XS, give symbolic names to the Perl version thresholds

  * jump through hoops to avoid compiler warnings

  * use full stricture in test suite

  * also test POD coverage of pure Perl implementation

  * in t/setup_pp.pl, avoid a warning that occurs if XSLoader::load()
    is given no arguments, which is now a valid usage

  * in Build.PL, explicitly set needs_compiler to avoid bogus
    auto-dependency on ExtUtils::CBuilder

  * in Build.PL, complete declaration of configure-time requirements
2011-08-14 16:26:57 +00:00
obache
39619a9444 Revision bump after updating perl5 to 5.14.1. 2011-08-14 12:26:04 +00:00
seb
c3f1e700ad Bump the PKGREVISION for all packages which depend directly on perl,
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.

The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.

sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
2010-08-21 16:32:42 +00:00
seb
8bb510f038 Update p5-Lexical-SealRequireHints from version 0.002 to version 0.003.
Upstream changes:
version 0.003; 2010-04-10

  * bugfix: in pure-Perl implementation, make sure ambient package (from
    which require is invoked) is passed on correctly to the code in the
    required file, on those Perls where it is so inherited

  * in XS, use macros to avoid explicit passing of aTHX, in the manner
    of the core

  * in XS, avoid using "class" as a variable name, for compatibility
    with C++ compilers

  * make all numeric comparisons against $] stringify it first, to avoid
    architecture-dependent problems with floating point rounding giving
    it an unexpected numeric value

  * in Build.PL, explicitly declare configure-time requirements

  * add MYMETA.yml to .cvsignore
2010-04-24 16:22:19 +00:00
sno
4515b835c6 Importing p5-Lexical-SealRequireHints version 0.002
There is a bug in Perl's handling of the %^H (lexical hints) variable that
causes lexical state in one file to leak into another that is required/used
from it. This bug will probably be fixed in Perl 5.10.2, and is definitely
fixed in Perl 5.11.0, but in any earlier version it is necessary to work
around it. On versions of Perl that require a fix, this module globally
changes the behaviour of require and use so that they no longer exhibit the
bug. This is the most convenient kind of workaround, and is meant to be
invoked by modules that make use of lexical state.

The workaround supplied by this module takes effect the first time its
import method is called. Typically this will be done by means of a use
statement. This should be done before putting anything into %^H that would
have a problem with leakage; usually it suffices to do this when loading
the module that supplies the mechanism to set up the vulnerable lexical
state. Invoking this module multiple times, from multiple lexical-related
modules, is not a problem: the workaround is only applied once, and applies
to everything.
2010-04-09 08:15:06 +00:00