Skip to content

Commit 494c34e

Browse files
committed
pod/ - document $INC and INCDIR
1 parent 9e31471 commit 494c34e

File tree

3 files changed

+153
-26
lines changed

3 files changed

+153
-26
lines changed

pod/perldelta.pod

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,37 @@ the caller provided an undefined or false value (respectively), rather than
3535
simply when the parameter is missing entirely. For more detail see the
3636
documentation in L<perlsub>.
3737

38+
=head2 @INC Hook Enhancements and $INC and INCDIR
39+
40+
The internals for C<@INC> hooks have been hardened to handle various
41+
edge cases and should no longer segfault or throw assert failures when
42+
hooks modify C<@INC> during a require operation. As part of this we
43+
now ensure that any given hook is executed at most once during a require
44+
call, and that any duplicate directories do not trigger additional
45+
directories probes.
46+
47+
To provide developers more control over dynamic module lookup a new hook
48+
method C<INCDIR> is now supported. An object supporting this method may be
49+
injected into the C<@INC> array, and when it is encountered in the module
50+
search process it will be executed, just like how INC hooks are executed,
51+
and its return value used as a list of directories to search for the
52+
module. Returning an empty list acts as a no-op. Note that any references
53+
returned by this hook will be stringified and used as strings, you may not
54+
return a hook to be executed later via this API.
55+
56+
When an C<@INC> hook (either C<INC> or C<INCDIR>) is called during
57+
require the C<$INC> variable will be localized to be the value of the
58+
index of C<@INC> that the hook came from. If the hook wishes to override
59+
what the "next" index in C<@INC> should be it may update C<$INC> to be one
60+
less than the desired index (C<undef> is equivalent to C<-1>). This
61+
allows an C<@INC> hook to completely rewrite the C<@INC> array and have
62+
perl restart its directory probes from the beginning of C<@INC>.
63+
64+
Blessed CODE references in C<@INC> that do not support the C<INC> or
65+
C<INCDIR> methods will no longer trigger an exception, and instead will
66+
be treated the same as unblessed coderefs are, and executed as though
67+
they were an C<INC> hook.
68+
3869
=head1 Security
3970

4071
XXX Any security-related notices go here. In particular, any security

pod/perlfunc.pod

Lines changed: 105 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -6716,8 +6716,14 @@ would have semantics similar to the following:
67166716
croak "Compilation failed in require";
67176717
}
67186718

6719-
foreach $prefix (@INC) {
6720-
if (ref($prefix)) {
6719+
local $INC;
6720+
# this type of loop lets a hook overwrite $INC if they wish
6721+
for($INC = 0; $INC < @INC; $INC++) {
6722+
my $prefix = $INC[$INC];
6723+
if (!defined $prefix) {
6724+
next;
6725+
}
6726+
if (ref $prefix) {
67216727
#... do other stuff - see text below ....
67226728
}
67236729
# (see text below about possible appending of .pmc
@@ -6800,16 +6806,20 @@ F<.pmc> extension. If this file is found, it will be loaded in place of
68006806
any file ending in a F<.pm> extension. This applies to both the explicit
68016807
C<require "Foo/Bar.pm";> form and the C<require Foo::Bar;> form.
68026808

6803-
You can also insert hooks into the import facility by putting Perl code
6804-
directly into the L<C<@INC>|perlvar/@INC> array. There are three forms
6805-
of hooks: subroutine references, array references, and blessed objects.
6809+
You can also insert hooks into the import facility by putting Perl
6810+
coderefs or objects directly into the L<C<@INC>|perlvar/@INC> array.
6811+
There are two types of hooks, INC filters, and INCDIR hooks, and there
6812+
are three forms of representing a hook: subroutine references, array
6813+
references, and blessed objects.
68066814

68076815
Subroutine references are the simplest case. When the inclusion system
6808-
walks through L<C<@INC>|perlvar/@INC> and encounters a subroutine, this
6809-
subroutine gets called with two parameters, the first a reference to
6810-
itself, and the second the name of the file to be included (e.g.,
6811-
F<Foo/Bar.pm>). The subroutine should return either nothing or else a
6812-
list of up to four values in the following order:
6816+
walks through L<C<@INC>|perlvar/@INC> and encounters a subroutine, unless
6817+
this subroutine is blessed and supports an INCDIR hook this
6818+
subroutine will be assumed to be an INC hook will be called with two
6819+
parameters, the first a reference to itself, and the second the name of
6820+
the file to be included (e.g., F<Foo/Bar.pm>). The subroutine should
6821+
return either nothing or else a list of up to four values in the
6822+
following order:
68136823

68146824
=over
68156825

@@ -6848,10 +6858,37 @@ Note that this filehandle must be a real filehandle (strictly a typeglob
68486858
or reference to a typeglob, whether blessed or unblessed); tied filehandles
68496859
will be ignored and processing will stop there.
68506860

6851-
If the hook is an array reference, its first element must be a subroutine
6852-
reference. This subroutine is called as above, but the first parameter is
6853-
the array reference. This lets you indirectly pass arguments to
6854-
the subroutine.
6861+
If the hook is an object, it should provide an C<INC> or C<INCDIR>
6862+
method that will be called as above, the first parameter being the
6863+
object itself. If it does not provide either method, and the object is
6864+
not CODE ref then an exception will be thrown, otherwise it will simply
6865+
be executed like an unblessed CODE ref would. Note that you must fully
6866+
qualify the method name when you declare an C<INC> sub (unlike the
6867+
C<INCDIR> sub), as the unqualified symbol C<INC> is always forced into
6868+
package C<main>. Here is a typical code layout for an C<INC> hook:
6869+
6870+
# In Foo.pm
6871+
package Foo;
6872+
sub new { ... }
6873+
sub Foo::INC {
6874+
my ($self, $filename) = @_;
6875+
...
6876+
}
6877+
6878+
# In the main program
6879+
push @INC, Foo->new(...);
6880+
6881+
If the hook is an array reference, its first element must be a
6882+
subroutine reference or an object as described above. When the first
6883+
element is an object that supports an C<INC> or C<INCDIR> method then
6884+
the method will be called with the object as the first argument, the
6885+
filename requested as the second, and the hook array reference as the
6886+
the third. When the first element is a subroutine then it will be
6887+
called with the array as the first argument, and the filename as the
6888+
second, no third parameter will be passed in. In both forms you can
6889+
modify the contents of the array to provide state between calls, or
6890+
whatever you like.
6891+
68556892

68566893
In other words, you can write:
68576894

@@ -6871,24 +6908,66 @@ or:
68716908
...
68726909
}
68736910

6874-
If the hook is an object, it must provide an C<INC> method that will be
6875-
called as above, the first parameter being the object itself. (Note that
6876-
you must fully qualify the sub's name, as unqualified C<INC> is always forced
6877-
into package C<main>.) Here is a typical code layout:
6911+
or:
68786912

6879-
# In Foo.pm
6880-
package Foo;
6881-
sub new { ... }
6882-
sub Foo::INC {
6883-
my ($self, $filename) = @_;
6913+
push @INC, [ HookObj->new(), $x, $y, ... ];
6914+
sub HookObj::INC {
6915+
my ($self, $filename, $arrayref)= @_;
6916+
my (undef, @parameters) = @$arrayref;
68846917
...
68856918
}
68866919

6887-
# In the main program
6888-
push @INC, Foo->new(...);
6889-
68906920
These hooks are also permitted to set the L<C<%INC>|perlvar/%INC> entry
68916921
corresponding to the files they have loaded. See L<perlvar/%INC>.
6922+
Should an C<INC> hook not do this then perl will set the C<%INC> entry
6923+
to be the hook reference itself.
6924+
6925+
A hook may also be used to rewrite the C<@INC> array. While this might
6926+
sound strange, there are situations where it can be very useful to do
6927+
this. Such hooks usually just return undef and do not mix filtering and
6928+
C<@INC> modifications. While in older versions of perl having a hook
6929+
modify C<@INC> was fraught with issues and could even result in
6930+
segfaults or assert failures, as of 5.37.7 the logic has been made much
6931+
more robust and the hook now has control over the loop iteration if it
6932+
wishes to do so.
6933+
6934+
There is a now a facility to control the iterator for the C<@INC> array
6935+
traversal that is performed during require. The C<$INC> variable will be
6936+
initialized with the index of the currently executing hook. Once the
6937+
hook returns the next slot in C<@INC> that will be checked will be the
6938+
integer successor of value in C<$INC> (or -1 if it is undef). For example
6939+
the following code
6940+
6941+
push @INC, sub {
6942+
splice @INC, $INC, 1; # remove this hook from @INC
6943+
unshift @INC, sub { warn "A" };
6944+
undef $INC; # reset the $INC iterator so we
6945+
# execute the newly installed sub
6946+
# immediately.
6947+
};
6948+
6949+
would install a sub into C<@INC> that when executed as a hook (by for
6950+
instance a require of a file that does not exist), the hook will splice
6951+
itself out of C<@INC>, and add a new sub to the front that will warn
6952+
whenever someone does a require operation that requires an C<@INC>
6953+
search, and then immediately execute that hook.
6954+
6955+
Prior to 5.37.7, there was no way to cause perl to use the newly
6956+
installed hook immediately, or to inspect any changed items in C<@INC> to
6957+
the left of the iterator, and so the warning would only be generated on
6958+
the second call to require. In more recent perl the presence of the last
6959+
statement which undefines C<$INC> will cause perl to restart the
6960+
traversal of the C<@INC> array at the beginning and execute the newly
6961+
installed sub immediately.
6962+
6963+
Whatever value C<$INC> held, if any, will be restored at the end of the
6964+
require. Any changes made to C<$INC> during the lifetime of the hook
6965+
will be unrolled after the hook exits, and its value only has meaning
6966+
immediately after execution of the hook, thus setting C<$INC> to some
6967+
value prior to executing a C<require> will have no effect on how the
6968+
require executes at all.
6969+
6970+
As of 5.37.7 C<@INC> values of undef will be silently ignored.
68926971

68936972
For a yet-more-powerful import facility, see
68946973
L<C<use>|/use Module VERSION LIST> and L<perlmod>.

pod/perlvar.pod

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -542,6 +542,23 @@ by default inserted into C<%INC> in place of a filename. Note, however,
542542
that the hook may have set the C<%INC> entry by itself to provide some more
543543
specific info.
544544

545+
=item $INC
546+
X<$INC>
547+
548+
As of 5.37.7 when an C<@INC> hook is executed the index of the C<@INC>
549+
array that holds the hook will be localized into the C<$INC> variable.
550+
When the hook returns the integer successor of its value will be used to
551+
determine the next index in C<@INC> that will be checked, thus if it is
552+
set to -1 (or C<undef>) the traversal over the C<@INC> array will be
553+
restarted from its beginning.
554+
555+
Normally traversal through the C<@INC> array is from beginning to end
556+
(C<0 .. $#INC>), and if the C<@INC> array is modified by the hook the
557+
iterator may be left in a state where newly added entries are skipped.
558+
Changing this value allows an C<@INC> hook to rewrite the C<@INC> array
559+
and tell Perl where to continue afterwards. See L<perlfunc/require> for
560+
details on C<@INC> hooks.
561+
545562
=item $INPLACE_EDIT
546563

547564
=item $^I

0 commit comments

Comments
 (0)