[swift/main] Migrate to internal imports #756
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
As of the Swift 6 compiler, `@_implementationOnly import` is deprecated in favor of `internal import` and as a result the use of `@_implementationOnly import` in this project is generating a lot of diagnostic noise when building the Swift standard library. For Swift libraries with library evolution, `@_implementationOnly import` and `internal import` are roughly functionally equivalent, aside from improved diagnostics for `internal import`. For non-resilient libraries, the main difference is that `internal import` does not actually hide a module dependency from downstream clients because the layout of a type in a non-resilient library may depend on types coming from an `internal import` (with `@_implementationOnly import` the same situation would result in a silent mis-compile, which is the reason that `@_implementationOnly import` is deprecated). The `_RegexParser` module dependency does not need to be hidden from clients since it is installed in standard locations in the SDK/toolchain. Therefore this migration should be safe, regardless of library resilience mode.
Contributor Author
| @swift-ci please test |
Member
| @swift-ci please test Windows |
1 similar comment
Contributor Author
| @swift-ci please test Windows |
milseman approved these changes Jul 26, 2024
Member
milseman left a comment
milseman left a comment There was a problem hiding this comment.
LGTM.
I'm not familiar with internal import, is there a semantic difference or is that the public spelling for it?
Contributor Author
|
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Cherry pick of #755.
As of the Swift 6 compiler,
@_implementationOnly importis deprecated in favor ofinternal importand as a result the use of@_implementationOnly importin this project is generating a lot of diagnostic noise when building the Swift standard library.For Swift libraries with library evolution,
@_implementationOnly importandinternal importare roughly functionally equivalent, aside from improved diagnostics forinternal import. For non-resilient libraries, the main difference is thatinternal importdoes not actually hide a module dependency from downstream clients because the layout of a type in a non-resilient library may depend on types coming from aninternal import(with@_implementationOnly importthe same situation would result in a silent mis-compile, which is the reason that@_implementationOnly importis deprecated). The_RegexParsermodule dependency does not need to be hidden from clients since it is installed in standard locations in the SDK/toolchain. Therefore this migration should be safe, regardless of library resilience mode.