-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cxx-interop] Fix SR-13785 #34476
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
[cxx-interop] Fix SR-13785 #34476
Conversation
@swift-ci please test |
Build failed |
Build failed |
…ility when dealing with @_implementationOnly imports
e1ec45e
to
679ce36
Compare
@swift-ci please test |
Build failed |
@swift-ci please test |
@swift-ci please test |
cc/ @gribozavr |
The approach makes sense, but I have some (possibly half-baked) ideas about the implementation. The main point is that this patch’s algorithm to gather transitive modular dependencies shouldn’t be needed. The set of modules given by |
I'm not sure I understand the idea. Say we have the following module structures, with
In the first example the clang module D is not visible, so we cannot use decls from it, while in the second example D is visible, so Swift shouldn't error out when A is using decls from D. How would
IIUC what you suggest would allow us to lookup the wrapper module of the ClangModule directly in the set of transitive modules as opposed to collecting the clang modules. We could do this even with the current code, if that's your preference. |
CC @hlopko |
… for visible access path between 2 modules
@CodaFi - I learned that |
@swift-ci please test |
1 similar comment
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as a first go. I'm concerned about the average running time of this new check. It might be worth it to e.g. build a table in the clang importer to amortize the cost here.
@swift-ci test compiler performance |
@CodaFi can you PTAL at the results? Seems like there is no impact on average running time, is it okay to merge this? |
⛵ |
These results confirm that we're not setup to measure the full impact here. Because we're just running source compat a bunch of times on macOS builders, it's unlikely we're hitting this code path with enough regularity to see a win or a loss. |
Currently, when Swift tries to validate that only visible declarations are used in the module's public interface, it sometimes rejects decls that come from
@_implementationOnly
modules, even in the case where there is a second, non@_implementationOnly
module that exports the decl (SR-13785). It is common that a single C/C++ header ends up being textually included in multiple Clang modules, triggering the issue.To address this, before rejecting a decl as not visible, we inspect all non-implementation-only modules transitively reachable from the source file. If a redeclaration exists in one of those modules, Swift won't error out anymore.
This allows us to fix build failures on Foundation caused by PR #32404.