Skip to content

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

Open
compnerd opened this issue May 9, 2025 · 6 comments
Open

Change default to *not* prefer textual interfaces #1893

compnerd opened this issue May 9, 2025 · 6 comments

Comments

@compnerd
Copy link
Member

compnerd commented May 9, 2025

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.

@compnerd
Copy link
Member Author

compnerd commented May 9, 2025

CC: @etcwilde

@artemcm
Copy link
Contributor

artemcm commented May 9, 2025

CC: @xymus

@xymus
Copy link
Contributor

xymus commented May 9, 2025

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?

@compnerd
Copy link
Member Author

compnerd commented May 9, 2025

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.

@xymus
Copy link
Contributor

xymus commented May 9, 2025

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?

@compnerd
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants