Skip to content

AST: Weak-link declarations in extensions of weak-linked types #29184

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 3 commits into from
Jan 14, 2020

Conversation

slavapestov
Copy link
Contributor

This is a workaround to fix weak linking of frameworks that define
types with availability, but then define extensions of those types
without availability.

This can come up if the framework itself is built with a newer
deployment target than the client that uses the framework. Since the
type checker only enforces that an extension has availability if
the extension is less available than the deployment target, we were
failing to weak link the members of the extension in this case.

This is not a perfect fix; ideally such frameworks should be built
with -require-explicit-availability, and all reported warnings
fixed by adding explicit availability.

However, it allows clients to weak link when using existing
swiftinterface files that have already shipped in the mean time,
and it should not cause any problems once the frameworks are properly
annotated in the future.

Fixes rdar://problem/58490723.

…ntend jobs

Unless you do this, the flag has no effect when used with the driver;
it only worked in conjunction with -Xfrontend.

Noticed while working on <rdar://problem/58490723>.
This is a workaround to fix weak linking of frameworks that define
types with availability, but then define extensions of those types
without availability.

This can come up if the framework itself is built with a newer
deployment target than the client that uses the framework. Since the
type checker only enforces that an extension has availability if
the extension is less available than the deployment target, we were
failing to weak link the members of the extension in this case.

This is not a perfect fix; ideally such frameworks should be built
with -require-explicit-availability, and all reported warnings
fixed by adding explicit availability.

However, it allows clients to weak link when using existing
swiftinterface files that have already shipped in the mean time,
and it should not cause any problems once the frameworks are properly
annotated in the future.

Fixes <rdar://problem/58490723>.
@slavapestov slavapestov requested review from xymus and aciidgh January 14, 2020 03:51
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@aciidgh
Copy link
Contributor

aciidgh commented Jan 14, 2020

👌

@slavapestov slavapestov merged commit 9b4906d into swiftlang:master Jan 14, 2020
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