Skip to content

Prevent shadowing of unavailable member impls #79094

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
Feb 1, 2025

Conversation

beccadax
Copy link
Contributor

@beccadax beccadax commented Feb 1, 2025

Typically, access control denies access to member implementations, so the imported interface decl will be used instead. However, in contexts that permit direct access to stored properties—such as accessors, inits, and deinits—their member implementations are accessible; the compiler then relies on a shadowing rule favoring Swift decls over ObjC decls to eliminate the imported interface decl.

However, there are many rules that are higher-priority than the Swift vs. ObjC decls one. In particular, a recent change to availability checking in #77886 caused a higher-priority rule to begin eliminating member implementations which belonged to unavailable extensions. This caused regressions in projects using @objc @implementation with classes that are unavailable in Mac Catalyst.

Introduce a fairly high-priority shadowing rule that favors a member implementation over its interface when both are present (i.e. when direct access to storage is permitted).

Fixes rdar://143582383.

Typically, access control denies access to member implementations, so the imported interface decl will be used instead. However, in contexts that permit direct access to stored properties—such as accessors, inits, and deinits—their member implementations are accessible; the compiler then relies on a shadowing rule favoring Swift decls over ObjC decls to eliminate the imported interface decl.

However, there are many rules that are higher-priority than the Swift vs. ObjC decls one. In particular, a recent change to availability checking in swiftlang#77886 caused a higher-priority rule to begin eliminating member implementations which belonged to unavailable extensions. This caused regressions in projects using `@objc @implementation` with classes that are unavailable in Mac Catalyst.

Introduce a fairly high-priority shadowing rule that favors a member implementation over its interface when both are present (i.e. when direct access to storage is permitted).

Fixes rdar://143582383.
@beccadax
Copy link
Contributor Author

beccadax commented Feb 1, 2025

@swift-ci please test

Copy link
Contributor

@nkcsgexi nkcsgexi left a comment

Choose a reason for hiding this comment

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

This is a great finding. Thank you for getting to the bottom of it, Becca!

@beccadax beccadax enabled auto-merge February 1, 2025 06:36
@beccadax beccadax merged commit 69a77d8 into swiftlang:main Feb 1, 2025
4 of 5 checks passed
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