utils: remove swiftinterfaces from the build image #79840
Conversation
|
Please test with following PRs: @swift-ci please smoke test |
|
Please test with following PRs: @swift-ci please build toolchain Windows platform |
|
CC: @xymus |
These cannot be re-serialized due to a bug in the serialization logic where we do not inject the VFS overlay for the system modules. Bug: swiftlang#79839
|
Please test with following PRs: @swift-ci please build toolchain Windows platform |
|
Please test with following PRs: @swift-ci please smoke test |
1 similar comment
|
Please test with following PRs: @swift-ci please smoke test |
There was a problem hiding this comment.
I tested this in #79185 and this specific aspect is working in CI with the tiny fix below.
|
@swift-ci please smoke test macOS platform |
|
Please test with following PRs: @swift-ci please test Windows platform |
|
Please test with following PRs: @swift-ci please build toolchain Windows platform |
|
CC: @xymus |
|
It looks like this will correctly work around the change from #79588. Relying only on binary swiftmodules for a local build should be fine, but I would caution against it for distributed SDKs and toolchains. For more context, we're very slowly moving towards using more and more textual swiftinterfaces for distributed modules. Binary swiftmodules are not designed to support changes in dependencies. Notably, a change to imported headers can force the compiler to drop entire decls, that's in the degraded mode as it crashes otherwise. So when building the modules on one machine and deploying on a different one the binary swiftmodules may be unusable, whereas swiftinterfaces are designed to be rebuilt on each machine against the local dependencies. |
|
@xymus hmm, the problem is that the re-serialization will fail with module not found errors for underlying clang modules. I suspect that this is due to VFS overlays not being applied when re-serialising the modules. |
|
swiftlang/swift-installer-scripts#400 @swift-ci please test Windows |
|
The Windows test failed, because PR testing is blocked right now (see swiftlang/swift-build#300). We need this patch (or a improved variant of it) to unblock the Windows x64 mainline bot: https://ci-external.swift.org/job/swift-main-windows-toolchain/ It would be great to get this bot back to green before I land my PR for the Android Swift Runtime tests. One of the PR-test runs over there demonstrated the effectiveness of the patch from this PR in combination with the installer-scripts patch linked above: https://ci-external.swift.org/job/swift-PR-windows/37567/ What is the state here? Can we land this once we get PR-testing unblocked? |
|
I think that we can merge it for unblocking the nightlies but would need to restore the swiftinterfaces soon. I think that #79926 might be the key to that. |
|
swiftlang/swift-installer-scripts#400 |
|
I checked that #79926 does not fix this particular issue. It feels like we need some changes to similar to 79926 to fix this issue so far but I haven't figured out yet. I'm on it. |
|
swiftlang/swift-installer-scripts#400 |
These cannot be reserialized due to a bug in the serialization logic where we do not inject the VFS Ovelay for the system modules.
Bug: #79839