Skip to content

Conversation

@elsh
Copy link
Contributor

@elsh elsh commented Dec 6, 2023

Currently, a package symbol imported via @_implementationOnly is permitted in a package interface declaration, and can be accessed by its client, potentially leading to a ub. It should not be allowed as the package symbol in such scenario should be treated as internal details.

This PR addresses the issue by treating a package decl as exported, as it is "public" within a package boundary.

Ref rdar://117586046

Currently, a package symbol imported via @_implementationOnly
is permitted in a package interface declaration, and can be
accessed by its client, potentially leading to a ub. It should
not be allowed as the package symbol in such scenario should
be treated as internal details.

This PR addresses the issue by treating a package decl as exported,
as it is "public" within a package boundary.

Ref rdar://117586046
@elsh
Copy link
Contributor Author

elsh commented Dec 6, 2023

@swift-ci test

@elsh elsh requested review from artemcm and xymus December 6, 2023 10:21
@xymus
Copy link
Contributor

xymus commented Dec 6, 2023

I would expect this change to the exportability logic to covert more cases. Could you add tests for those as well?

I'm thinking about references from inlinable code (you can probably reuse parts of the tests in #64033), references through conformances and typealias underlying (see the tests in #68776) and extensions to implementation-only imported types (see tests in #68954).

@elsh
Copy link
Contributor Author

elsh commented Jan 23, 2024

Will revisit after other PRs are merged.

@elsh
Copy link
Contributor Author

elsh commented May 2, 2024

Closing as addressed in a separate PR.

@elsh elsh closed this May 2, 2024
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