[cxx-interop] Import private members #78942
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit removes the guardrails in ImportDecl.cpp:SwiftDeclConverter that prevent it from importing non-public C++ members. It also accordingly adjusts all code that assumes generated Swift decls should be public.
… global functions
j-hui
added
c++ interop
|
The size of this patch reflects the fact that, prior to this work, the ClangImporter had assumed that all imported C++ code would be public in Swift. This assumption has already been selectively invalidated by #76892. I'm hesitant (and unsure of how) to break this up into smaller pieces, because I am worried about inadvertently importing something as public that should really be private, and causing assertion failures where the Swift compiler enforces that public declarations should not expose private ones. Also note that I haven't updated the test cases just yet so CI will report breakage if I run it. |
…f public global functions" This reverts commit 7d0ba28.
|
@swift-ci Please smoke test |
j-hui
requested review from
zoecarver,
hyp,
egorzhdan,
Xazax-hun,
beccadax,
ian-twilightcoder,
hborla,
slavapestov and
xedin
as code owners
|
Xazax-hun
reviewed
Jan 29, 2025
|
@swift-ci Please test |
Xazax-hun
approved these changes
Jan 30, 2025
Xazax-hun
reviewed
Jan 30, 2025
|
@swift-ci Please test |
j-hui
added a commit
that referenced
this pull request
Feb 25, 2025
This patch is follow-up work from #78942 and imports non-public members, which were previously not being imported. Those members can be accessed in a Swift file blessed by the SWIFT_PRIVATE_FILEID annotation. As a consequence of this patch, we are also now importing inherited members that are inaccessible from the derived classes, because they were declared private, or because they were inherited via nested private inheritance. We import them anyway but mark them unavailable, for better diagnostics and to (somewhat) simplify the import logic for inheritance. Because non-public base class members are now imported too, this patch inflames an existing issue where a 'using' declaration on an inherited member with a synthesized name (e.g., operators) produces duplicate members, leading to miscompilation (resulting in a runtime crash). This was not previously noticed because a 'using' declaration on a public inherited member is not usually necessary, but is a common way to expose otherwise non-public members. This patch puts in a workaround to prevent this from affecting the behavior of MSVC's std::optional implementation, which uses this pattern of 'using' a private inherited member. That will be fixed in a follow-up patch. Follow-up work is also needed to correctly diagnose ambiguous overloads in cases of multiple inheritance, and to account for virtual inheritance. rdar://137764620
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch imports non-public (i.e., private and protected) non-inherited members from C++ to Swift.
Importing non-public inherited members will be done in a follow-up patch, since it involves some tricky but self-contained logic to deal with how private and protected inheritance affect C++ access levels (and thus how they should be reflected in Swift).
The purpose of this patch is to eventually allow such members to be accessed in certain Swift files, according to the feature pitched here: https://forums.swift.org/t/feature-proposal-accessing-non-public-c-members-from-swift/76116.
For now, this patch should not change the behavior of existing interop code, except that it should turn some "privateMember does not exist" errors into "privateMember cannot be access because it is private" (which better reflects why it cannot be accessed in Swift).
This PR is another attempt at the work I tried to do in #77726, which became too large. Another patch will follow that allows Swift to access these imported private members.
rdar://137764620