-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ModuleInterface] Print missing imports in swiftinterface #60659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hack to fix swiftinterfaces in case of missing imports. We can get rid of this logic when we don't leak the use of non-locally imported things in API.
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
Added a note to the warning to explain that the import i implicitly added. This should help if anyone wonders where the import comes from in the swiftinterface. @swift-ci Please smoke test |
lib/AST/Module.cpp
Outdated
@@ -2535,6 +2546,20 @@ RestrictedImportKind SourceFile::getRestrictedImportKind(const ModuleDecl *modul | |||
if (imports.isImportedBy(module, getParentModule())) | |||
return RestrictedImportKind::None; | |||
|
|||
if (importKind == RestrictedImportKind::Implicit && | |||
module->getLibraryLevel() == LibraryLevel::API) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to restrict this to LibraryLevel::API
? I thought the majority of cases where this would help are actually LibraryLevel::SPI
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should not implicitly import SPI modules in the public swiftinterfaces of API modules. However, I think that this would address more broken interfaces if it also handled references to implicitly imported SPI modules in SPI decls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see this being complex to get right, though, and it might not be immediately necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I restricted it to API to avoid breaking swiftinterfaces by inserting public imports of SPI modules. Yeah, that's too restrictive. I'll also allow adding any import when the source is part of a non API module. This would be in line with the current diagnostics about "public import of a private module from a public module".
We could also consider always adding the missing import if this remains a common issue. This would be more appropriate if we decided to make this as an error before Swift 6.
We can insert imports to any module from a source file that's part of a non-API module without risking breaking the public swiftinterface.
Now it inserts missing imports to any modules from a non-API module. @swift-ci Please smoke test |
We already diagnose the use in API of a module that is not imported, let's use that information to print the missing imports in the swiftinterfaces. We can get rid of this hack when we don't leak the use of non-locally imported things in API.