[Serialization] Always list the bridging header before any imports #17186
Conversation
|
Thanks to Adrian for heroically coming up with a reduced test case! @swift-ci Please test |
|
@swift-ci Please test source compatibility |
| // #if __clang__ | ||
| // | ||
| // #ifndef AP | ||
| // #define AP |
There was a problem hiding this comment.
Oops, left some testing code in.
jrose-apple
force-pushed
the
bridge-over-troubled-imports
branch
from
a06dd61 to
801e323
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
This can only happen in one case today: a module imports a bridging header, but the header on disk has disappeared, and now we need to fall back to the (often inadequate) version that's stored inside the swiftmodule file. Even if the module fails to load, the bridging header has already been imported, and so anything else that happens might still emit diagnostics and need that text to be alive, which means we need to keep the buffer alive too.
This mirrors how a bridging header is processed when compiling source files: before any of the imports. This is important for LLDB to recreate the source environment as closely as possible to how the compiler does it; in the test case being added involving a non-modular header file, failure to do so resulted in a deserialization cross-reference crash. Note that Serialization still sorts imports, which normal resolution of imports in source does not do. So we're still not consistent. But this is less important than handling textual includes (bridging headers) before modular imports. rdar://problem/40471329
jrose-apple
force-pushed
the
bridge-over-troubled-imports
branch
from
801e323 to
6dcda93
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
|
@swift-ci Please test source compatibility |
|
This looks good to me. I like that it syncs up the behavior with normal compiles, to cope with any textual include weirdness in bridging headers. Thanks! |
…led-imports [Serialization] Always list the bridging header before any imports rdar://problem/40471329 (cherry picked from commit e5cec5f)
…led-imports [Serialization] Always list the bridging header before any imports rdar://problem/40471329 (cherry picked from commit e5cec5f)
This mirrors how a bridging header is processed when compiling source files: before any of the imports. This is important for LLDB to recreate the source environment as closely as possible to how the compiler does it; in the test case being added involving a non-modular header file, failure to do so resulted in a deserialization cross-reference crash.
Note that Serialization still sorts imports, which normal resolution of imports in source does not do. So we're still not consistent. But this is less important than handling textual includes (bridging headers) before modular imports.
rdar://problem/40471329