-
Notifications
You must be signed in to change notification settings - Fork 199
Change default to *not* prefer textual interfaces #1893
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
Comments
CC: @etcwilde |
CC: @xymus |
We should not be emitting textual interfaces without library-evolution being enabled. It's reported only as a warning but if we do we should certainly fix that configuration, or add logic to emit and then mark them as unusable during normal compilation if we consume them for other reasons. There are fundamental issues with serialized modules that required this change. We could apply a different behavior per OS as those issues may be worst on the Apple side. However, I'm under the impression that textual interfaces should be usable on other OSes even if there's no ABI stability guarantee as long as they are consumed by the same compiler that produced them. Are there other issues with using textual interfaces behind this request? |
I think that currently, emitting the textual interface requires library evolution, which I don't think we should be enabling on Windows. We currently are emitting textual interfaces in the old standard library build, and these are being packaged and shipped (incidentally, they have also found issues in the code). The other concern is that some projects (e.g. swift-testing) only distribute the swift interface and not the swift module. If we want to ship the textual interfaces without library evolution - then I think that we should ensure that the new build system also emits them. But if we cannot enable textual interfaces without library evolution, the textual interfaces should be a fallback not the default item that is loaded. |
If library-evolution is already disabled and we fix the configuration to stop emitting textual interfaces, the default won't matter right? There's no choice to be made by the compiler as only the serialized module will be present. Are we then looking for more of a temporary fix to support older SDKs or for compatibility with the old build system? |
I think that the default behaviour matters. IO performance on Windows is a noticeable part of the build times and extra stats are undesirable. So if we are going to be using swiftmodules, we should use that as the first item to check, not the last. |
Recent changes made the module loading prefer the textual interfaces. However, textual interfaces require library evolution. The old runtime build system emitted the textual interfaces without library evolution which is UB. We should default to the serialised modules.
The text was updated successfully, but these errors were encountered: