Skip to content

[swift/main] Migrate to internal imports #756

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

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
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.

3 participants