Skip to content

[ClangImporter] Handle submodule imports in bridging headers #14487

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

Conversation

jrose-apple
Copy link
Contributor

If a bridging header imported a submodule but not the top-level module, the top-level module would never be made visible. This is a problem since the Clang importer makes all top-level decls available through their enclosing top-level modules, not the individual submodules.

To fix this, stop special-casing the way we handle bridging header imports; we can translate them from Clang Modules to Swift ModuleDecls the same way we do for regular imports.

rdar://problem/37355259

This must have slipped in just before -typecheck was introduced,
back when -parse did that instead of /only/ parsing.
If a bridging header imported a submodule but /not/ the top-level
module, the top-level module would never be made visible. This is a
problem since the Clang importer makes all top-level decls available
through their enclosing top-level modules, not the individual
submodules.

To fix this, stop special-casing the way we handle bridging header
imports; we can translate them from Clang Modules to Swift ModuleDecls
the same way we do for regular imports.

rdar://problem/37355259
@jrose-apple jrose-apple force-pushed the bridge-over-troubled-modules branch from 0156a16 to 6754cc6 Compare February 8, 2018 19:36
@jrose-apple
Copy link
Contributor Author

The diff may be easier to read with whitespace changes ignored.

@swift-ci Please test

Copy link
Contributor

@graydon graydon left a comment

Choose a reason for hiding this comment

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

If I understand correctly (and it's still .. pretty blurry) the key goal here is to route the bridging header imported modules into the non-bridging-header logic marked "HACK: Deal with imports of submodules" around line 3061? If so, seems ok to me; I wouldn't have guessed this in a million years, so thanks for dealing with it!

@jrose-apple
Copy link
Contributor Author

Yes, that's it. That code already handles submodules, and what we had before didn't, so just stop doing what we had before.

@jrose-apple jrose-apple merged commit 5880e7d into swiftlang:master Feb 9, 2018
@jrose-apple jrose-apple deleted the bridge-over-troubled-modules branch February 9, 2018 00:52
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