Skip to content

Under -enable-library-evolution, imports need Library Evolution too #25549

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
Jun 18, 2019

Conversation

jrose-apple
Copy link
Contributor

Otherwise, there's no guarantee of binary compatibility, and whoever turned on library evolution support shouldn't be lulled into a false sense of security.

This is just a warning for now, but will be promoted to an error later once clients have shaken out any places where they're doing this. Note that the still-experimental @_implementationOnly opts out of this check, because that enforces that the import doesn't make its way into the current module's public source or binary interface.

rdar://50261171

Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.

This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.

rdar://50261171
/// Swift.
///
/// Right now that's just Clang modules.
bool isNonSwiftModule() const {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm planning follow-up work where I check on all uses of findUnderlyingClangModule() that don't actually need to check more than what this predicate is doing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oof, ModuleDecl::isClangModule already exists and I just didn't spot it. This is still a better implementation, but maybe I'll give up on my too-forward-looking name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

…and the one use of isClangModule is incorrect, because it looks through overlays.

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

@jrose-apple jrose-apple merged commit 2397bf4 into swiftlang:master Jun 18, 2019
@jrose-apple jrose-apple deleted the no-missing-link-here branch June 18, 2019 16:23
jrose-apple added a commit to jrose-apple/swift that referenced this pull request Jun 18, 2019
…wiftlang#25549)

Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.

This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.

rdar://50261171
(cherry picked from commit 2397bf4)
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.

2 participants