Skip to content

make calling an undefined import method a warning#24059

Merged
haarg merged 1 commit intobleadfrom
haarg/undefined-import-warning
Jan 27, 2026
Merged

make calling an undefined import method a warning#24059
haarg merged 1 commit intobleadfrom
haarg/undefined-import-warning

Conversation

@haarg
Copy link
Contributor

@haarg haarg commented Jan 6, 2026

Partial revert of f430ad8 (PR #23992)

This changes calling an undefined import or unimport method with arguments back to a warning, but not a deprecation. Making this fatal had a very large amount of fallout for extremely marginal gains. It has been decided that a warning is enough, and making it fatal in the future will not be pursued.

Fixes #24058

@haarg
Copy link
Contributor Author

haarg commented Jan 6, 2026

I chose undef_import as the warning category for this, but I'm not attached to it at all. I initially tried to reuse the missing_import_called_with_args name, but long names cause problems with the way the warnings page is currently formatted.

pod/perldiag.pod Outdated
Another common reason this may happen is when mistakenly attempting to
import or unimport a symbol from a class definition or package which
does not use C<Exporter> or otherwise define its own C<import> or
C<unimport> method.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be beneficial to include examples of at least the import sub-case for each of these two cases. The wording is sufficiently complex that I can't easily articulate the difference between the two.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of example do you have in mind?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the first paragraph of the proposed re-write of pod/perldiag.pod (You called the ...), the calling program -- let's call it Program A -- mistakenly thinks that package B either defines its own import method or has an import method in its inheritance graph.

In the second paragraph of the proposed re-write (Another common reason ...), the calling program mistakenly thinks that package B either defines its own import method gets an import method from Exporter.

Isn't the second case just a subset of the first case? If it is not, then we should have examples which clearly distinguish the two cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first paragraph starts with a direct description of what happened - no import method was found. Then it mentions a common case that could cause this - an incorrect package due to using the wrong case. The second paragraph describes another case, where the package is correct but has no import method when the user was expecting one.

The cause here is something missing. An example of something missing won't be easy to demonstrate in any way that makes sense without additional text, so I'm not sure the example really helps. If you have an example you think helps with this feel free to propose one.

@tonycoz
Copy link
Contributor

tonycoz commented Jan 7, 2026

Should this warning be enabled by default?

I believe the original intent of the fatalisation was catch mistakes like:

use Strict 'refs';

on case-insensitive file systems.

Making it require use warnings may mean that users who do need to see it, won't.

@haarg haarg force-pushed the haarg/undefined-import-warning branch 4 times, most recently from 304a245 to 7d5f756 Compare January 8, 2026 13:35
@haarg
Copy link
Contributor Author

haarg commented Jan 8, 2026

I've switched the warning to be enabled by default since it is likely to impact places where warnings haven't been enabled yet. It has also already been enabled by default as a deprecation for a couple releases.

@haarg haarg force-pushed the haarg/undefined-import-warning branch from 7d5f756 to ec2ddc4 Compare January 8, 2026 14:34
@ap
Copy link
Contributor

ap commented Jan 8, 2026

It has also already been enabled by default as a deprecation for a couple releases.

Right. I do think it should be enabled by default.

@haarg haarg force-pushed the haarg/undefined-import-warning branch from ec2ddc4 to c561490 Compare January 11, 2026 13:57
@leonerd
Copy link
Contributor

leonerd commented Jan 19, 2026

Code and tests all look fine, though I do wonder about the name. Specifically, "undef_import" makes me think of the perl undef value, which isn't related here. Could we call it "undefined_import" or "missing_import", or somesuch instead?

@haarg
Copy link
Contributor Author

haarg commented Jan 20, 2026

It is also possible to have an undefined sub that exists (a stub). missing_import seems reasonable. I suppose the warning message should also be changed to "missing".

@haarg
Copy link
Contributor Author

haarg commented Jan 21, 2026

I've updated the category to missing_import and changed the warning message to use "missing" rather than "undefined". I will squash the commits before merging.

Copy link
Contributor

@leonerd leonerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

pod/perldiag.pod Outdated
Comment on lines +1348 to +1349
This is very often the sign of a misspelled package name in a use or
require statement that has silently succeeded due to a case insensitive
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to have lost the C<> formatting on the use and require keywords.

Also, require doesn't call import, so should not be mentioned here, but instead no should, because that calls unimport.

Partial revert of f430ad8 (PR #23992)

This changes calling an missing import or unimport method with arguments
back to a warning, but not a deprecation. Making this fatal had a very
large amount of fallout for extremely marginal gains. It has been
decided that a warning is enough, and making it fatal in the future will
not be pursued.
@haarg haarg force-pushed the haarg/undefined-import-warning branch from 1cc19d6 to 969d598 Compare January 27, 2026 13:15
@haarg haarg merged commit ca3b185 into blead Jan 27, 2026
67 checks passed
haarg added a commit that referenced this pull request Feb 20, 2026
Add a perldelta entry for returning calling a missing import method to a
warning rather than an error.

The warning change was implemented in
969d598 (PR #24059).
haarg added a commit that referenced this pull request Feb 20, 2026
Add a perldelta entry for returning calling a missing import method to a
warning rather than an error.

The warning change was implemented in
969d598 (PR #24059).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

De-fatalize calling undefined import/unimport method with arguments

7 participants