[Clang Importer] Defer module imports to end of bridging-header parse. #7705
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
|
Remaining to deal with:
|
jrose-apple
reviewed
Feb 24, 2017
lib/ClangImporter/ImporterImpl.h
Outdated
| @@ -275,6 +275,7 @@ class LLVM_LIBRARY_VISIBILITY ClangImporter::Implementation | |||
|
|
|||
| bool IsReadingBridgingPCH; | |||
| llvm::SmallVector<clang::serialization::SubmoduleID, 2> PCHImportedSubmodules; | |||
| llvm::SmallVector<const clang::Module*, 2> ImportedModules; | |||
There was a problem hiding this comment.
Can you name this DeferredHeaderImports or something? ImportedModules makes it sound like something that stays valid and makes sense to ask for for the lifetime of the ClangImporter.
There is a subtle incompatibility between the way bridging headers handle module imports and the way clang's normal module-loading works (as done by -emit-pch in bridging PCH, in particular). When importing a submodule, Swift implicitly imports its supermodule. This is part of Swift's treatment of modules and fine, we're not changing it here. But if client code imports a submodule, then tries to use a type that is only defined in its supermodule, not the submodule, this _should_ cause a parse error (and does in clang alone, or when generating a PCH). Unfortunately Swift's "implicit parent import" currently happens eagerly, so the supermodule is imported and its type is defined as soon as the submodule is imported, which in turn suppresses the error. This in turn means that client code thinks their code "works" and then "breaks" when they turn on bridging PCH. What _should_ happen here is that the (actually broken) client code should not be accepted in the first place, neither bridging PCH nor textual bridging-header import. This commit merely changes textual bridging-header import from eager import to deferred parent-import, like bridging PCH does. This reconciles the difference in behaviour between the two, at the cost of a source-compat break. rdar://30615193
graydon
force-pushed
the
rdar-30615193-defer-module-import-from-bridging-header-until-finished-parse
branch
from
845ae28 to
416a12e
Compare
|
Decision was to land this for swift 4 timeframe, not swift 3.1, but consider it just a bug fix (with release note), not a behaviour to preserve under compat flag. |
|
@swift-ci please test and merge |
graydon
changed the title
graydon
deleted the
rdar-30615193-defer-module-import-from-bridging-header-until-finished-parse
branch
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.
There is a subtle incompatibility between the way bridging headers handle
module imports and the way clang's normal module-loading works (as done
by -emit-pch in bridging PCH, in particular).
When importing a submodule, Swift implicitly imports its supermodule. This
is part of Swift's treatment of modules and fine, we're not changing it
here.
But if client code imports a submodule, then tries to use a type that is
only defined in its supermodule, not the submodule, this should cause
a parse error (and does in clang alone, or when generating a PCH).
Unfortunately Swift's "implicit parent import" currently happens
eagerly, so the supermodule is imported and its type is defined as soon
as the submodule is imported, which in turn suppresses the error.
This in turn means that client code thinks their code "works" and then
"breaks" when they turn on bridging PCH. What should happen here is
that the (actually broken) client code should not be accepted in the first
place, neither bridging PCH nor textual bridging-header import.
This commit merely changes textual bridging-header import from eager
import to deferred parent-import, like bridging PCH does. This reconciles
the difference in behaviour between the two, at the cost of a source-compat
break.
rdar://30615193