8000 Platform: Update module maps for the static SDK by Steelskin · Pull Request #81826 · swiftlang/swift · GitHub
[go: up one dir, main page]

Skip to content

Platform: Update module maps for the static SDK #81826

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

Merged

Conversation

Steelskin
Copy link
Contributor

Building with the Windows static SDK uncovered issues in the Windows module maps. Some of the headers were missing and others had incorrect layering. This updates the module maps to build with the static Windows SDK.

@Steelskin Steelskin requested a review from a team as a code owner May 29, 2025 01:18
@compnerd
Copy link
Member

@swift-ci please test Windows platform

@@ -101,6 +123,11 @@ module ucrt [system] {
export *
}

module stdnoreturn {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this textual?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The textual annotation prevents the header from being compiled when the header is built. It is instead textually included on demand. It must still parse properly, mind you.
IIUC, for our use case, what this means is that its symbols are not directly included in the compiled stdnoreturn module but they will still be present in the ucrt module since this header is included by other headers in the module - this also applies to other textual headers defined here.
This is a hackier solution than I would like but it works for all of the Windows 10 SDK versions that I have tried.

complex.h is still being a pain because it includes ccomplex if you build it in C++ mode and also disables some symbols, which is just wrong IMO.

For the rest, we can rely on Swift tests. It has been my experience that they are rather extensive.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I understand the behaviour of the textual heaader. I am wondering what is the cycle that this is trying to break. It seems that there are two cycles present:

  1. stddef.h
  2. stdnoreturn.h

TBH, making these two textual to make things work as a workaround is fine. This is still a better state than we were in previously.

Steelskin added 2 commits June 2, 2025 15:24
Building with the Windows static SDK uncovered issues in the Windows
module maps. Some of the headers were missing and others had incorrect
layering. This updates the module maps to build with the static Windows
SDK.
@Steelskin Steelskin force-pushed the fabrice/update-ucrt-vcruntime-modulemap branch from 85494ba to 72dad03 Compare June 2, 2025 22:25
@compnerd
Copy link
Member
compnerd commented Jun 2, 2025

CC: @ian-twilightcoder - not sure if you have thoughts/suggestions on this, but I figured that I would try :)

@compnerd
Copy link
Member
compnerd commented Jun 2, 2025

@swift-ci please test Windows platform

@compnerd
Copy link
Member
compnerd commented Jun 3, 2025

@swift-ci please smoke test Linux platform

@compnerd
Copy link
Member
compnerd commented Jun 3, 2025

@swift-ci please smoke test macOS platform

@compnerd compnerd merged commit 478823c into swiftlang:main Jun 3, 2025
3 checks passed
@Steelskin Steelskin deleted the fabrice/update-ucrt-vcruntime-modulemap branch June 3, 2025 16:14
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

Successfully merging this pull request may close these issues.

2 participants
0