ModuleInterface: Setup logic to load distributed swiftinterfaces over swiftmodules by default #71617
Conversation
|
@swift-ci Please smoke test |
| @@ -444,11 +444,19 @@ NOTE(compiled_module_ignored_reason,none, | |||
| "|it belongs to a framework in the SDK" | |||
| "|loading from module interfaces is preferred" | |||
| "|it's a compiler host module" | |||
There was a problem hiding this comment.
Not new in this PR, but what does "host" mean in this context? When I see the diagnostic in the test, I find it a bit confusing since when I read "host" in a compilation context my impression is that it usually refers to a particular role in cross compilation. Here it just means it's in the resource dir, aka the toolchain, right?
There was a problem hiding this comment.
I believe it's for macros and refers to a cross-compilation concern, or at least bootstrapping.
@bnbarham Could you remind us why we ignore swiftmodules when isInResourceHostDir?
There was a problem hiding this comment.
This is really just an issue in our build/test infrastructure, as the modules won't even be there in the toolchain (or at least, they shouldn't be if they are 😅). The issue is that these libraries are built by the "host" (builder/) compiler, but are then read by the just-built compiler when eg. building libraries/executables in the tests. An alternative to this would be building the swiftmodule itself elsewhere during the build, I'd be open to that rather than this hack if you'd prefer as well.
There was a problem hiding this comment.
We'll need an option in build systems to not install swiftmodules at some point. For this PR we could improve the proposed diagnostic, it sounds like it will be mostly us seeing it.
The Swift compiler can load either the binary swiftmodule file or the textual swiftinterface file when importing a module. It currently picks the swiftmodule over the swiftinterface, unless there’s an exception. We should flip the default for distributed modules, prefer the swiftinterface over the swiftmodule unless there’s an exception. rdar://122955640
xymus
force-pushed
the
swiftinterface-by-default-mode
branch
from
d663696 to
4945cfc
Compare
|
@swift-ci Please smoke test |
|
What does this mean for explicit module build? |
|
@cachemeifyoucan This change should affect explicit builds in the same way as implicit builds. Explicit module builds schedules the job to populate the module cache which relies on this logic to chose between rebuilding the swiftinterface or writing down a forwarding module. |
Would be good to see a test for that case. |
|
@swift-ci Please smoke test |
1 similar comment
|
@swift-ci Please smoke test |
The Swift compiler can load either the binary swiftmodule file or the textual swiftinterface file when importing a module. It currently picks the swiftmodule over the swiftinterface, unless there’s an exception. We should flip the default for distributed modules, prefer the swiftinterface over the swiftmodule unless there’s an exception.
This PR only puts the logic in place, turning the new logic on by default will be done separately by adding the special blocklist item
Swift_UseSwiftinterfaceByDefault.rdar://122955640