Skip to content

[swift/main] Migrate to internal imports #756

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Jul 26, 2024

Conversation

tshortli
Copy link
Contributor

Cherry pick of #755.

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.

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.
@tshortli
Copy link
Contributor Author

@swift-ci please test

@shahmishal
Copy link
Member

@swift-ci please test Windows

1 similar comment
@tshortli
Copy link
Contributor Author

@swift-ci please test Windows

@milseman milseman requested a review from natecook1000 July 26, 2024 15:34
Copy link
Member

@milseman milseman left a comment

Choose a reason for hiding this comment

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

LGTM.

I'm not familiar with internal import, is there a semantic difference or is that the public spelling for it?

@tshortli
Copy link
Contributor Author

I'm not familiar with internal import, is there a semantic difference or is that the public spelling for it?

internal import is the product of SE-409. There are some type checking and compile time differences between the two, but internal import should be thought of as the official replacement for @_implementationOnly import.

@tshortli tshortli merged commit dcbd3c0 into swiftlang:swift/main Jul 26, 2024
3 checks passed
@tshortli tshortli deleted the internal-import-swift-main branch July 26, 2024 15:44
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants