Relevant:
commit e0affd782303c36cd73841538e531ceaf4a17b59
Author: Zefram <zefram@fysh.org>
Date: Thu Feb 6 20:46:57 2014 +0000
suppress any CORE::GLOBAL::require override
If require() is overridden, in a way that wraps the core's require(),
it is likely that error messages from the core require(), such as those
describing a module not being found, will incorporate the filename and
line number of the location where the override calls the core require(),
rather than the location of the normal require() call that got overridden.
As use_package_optimistically() looks at that part of the error message
to make its recognition more specific, an override is likely to break its
heuristic, making it perceive a real error rather than a missing module.
To avoid this, use "CORE::require" instead of just "require", suppressing
any override. This means that the module-not-found error message will
refer to Module/Runtime.pm even if there is an override.
There is some downside from suppressing overrides: they might be
doing something useful. The specific case of the overrides from
Lexical::SealRequireHints is not a problem, because Module::Runtime
incorporates the fix that L:SRH would provide via an override. On the
perl versions where M:R's workaround can't operate, L:SRH's pure Perl
version can't operate either. L:SRH's XS implementation, which does work
on those perl versions, applies to "CORE::require" just as to "require",
and doesn't affect error locations.
On perl versions prior to 5.8.9, "CORE::require" doesn't actually
suppress overrides. On those versions, the incompatibility of
use_package_optimistically() with CORE::GLOBAL::require remains. As it
seems unfixable, it is left for the time being as a known problem.
