Skip to content

[5.9] AST: Inherit access level of an opaque type decl from its naming decl #66516

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

Conversation

tshortli
Copy link
Contributor

@tshortli tshortli commented Jun 9, 2023

  • Explanation: When an OpaqueTypeDecl is constructed, the access level attributes of the decl that names the opaque type are copied on to it. However, the @usableFromInline attribute is not permitted on every type of decl, so it does not get copied. This in turn causes effective access level computations for opaque types to fail to take @usableFromInline into account and that results in the emitted symbol getting the wrong linkage during IRGen. The fix is to make the effective access computation take this quirk of opaque types into account directly, instead of relying on copying of attributes.
  • Scope: The change is narrow in the sense that the only type of declaration it affects is opaque type decls. However, access level is queried in many parts of the compiler.
  • Issues: rdar://110544170
  • Risk: Medium. Decl access level is queried from many different locations in the compiler so it's difficult to predict whether this change might expose any other issues.
  • Testing: Regression tests added.
  • Reviewers: @jckarter, @xedin
  • Main branch PR: AST: Inherit access level of an opaque type decl from its naming decl #66515.

When an `OpaqueTypeDecl` is constructed, the access level attributes of the
decl that names the opaque type are copied on to it. However, the
`@usableFromInline` attribute is not permitted on every decl, so it does not get
copied. This in turn causes effective access level computations for opaque
types to fail to take `@usableFromInline` into account and that results in the
emitted symbol getting the wrong linkage during IRGen. The fix is to make the
effective access computation take this quirk of opaque types into account
directly, instead of relying on copying of attributes.

Resolves rdar://110544170
@tshortli
Copy link
Contributor Author

tshortli commented Jun 9, 2023

@swift-ci please test

@tshortli tshortli marked this pull request as ready for review June 11, 2023 18:15
@tshortli tshortli requested a review from a team as a code owner June 11, 2023 18:16
@tshortli tshortli merged commit 4b3452a into swiftlang:release/5.9 Jun 12, 2023
@tshortli tshortli deleted the usable-from-inline-opaque-type-decl-linkage-5.9 branch June 12, 2023 03:45
tshortli added a commit that referenced this pull request Jun 12, 2023
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