[6.4] windows: enable bootstrapping by compnerd · Pull Request #89719 · swiftlang/swift

compnerd · 2026-06-05T19:48:56Z

Explanation: This cherry-picks over the large swath of changes (primarily to build.ps1) which enable the work needed for bootstrapping. More importantly, it enables the SxS bound toolchain which will be required to further the adoption of Swift in the Swift compiler.
Risk: Low. It basically only affects Windows. Also, it's only a change in the build system and not in the compiler itself.
Testing: by Windows CI testing
Issue: Windows bootstrapping support #90013
Reviewers: @DougGregor
Main branch PR: build: Windows bootstrapping support #88775

This is preparatory work to allow us to build multiple "experimental"-style SDKs for bootstrapping. (cherry picked from commit 995cfa2)

We already have a checkout for the dependencies of early-swift-driver. Reuse the existing sources rather than checking them out from git again. (cherry picked from commit f230c75)

(cherry picked from commit f6e4c72)

(cherry picked from commit 06c0608)

Use Remove-Item with -ErrorAction Stop for the output directories removed by -Clean. This keeps missing paths non-fatal, but aborts the build when a locked file or another removal error would leave stale output behind. Also shorten the -Clean help text. (cherry picked from commit 506b7e0)

Compute driver-specific compile and debug flags from compiler descriptors instead of keeping that logic inside Build-CMakeProject. This keeps Build-CMakeProject focused on applying a selected compiler, and makes later bootstrap-stage compiler definitions a straightforward extension of the same model. (cherry picked from commit 02d4020)

Thread explicit compiler selections through the SDK leaf builders for dispatch, zlib, brotli, libxml2, and curl. This lets each SDK phase build its dependencies with the compiler for that stage instead of reaching back to the pinned or host compiler globals. (cherry picked from commit e3005b0)

Add the first Windows bootstrap compiler image under the stage0 project cache. Install the compiler, Clang resource pieces, Swift Clang builtin headers, lld, and the SwiftSyntax DLLs needed by the staged compiler. Limit LLVM targets to the build architecture. The Bootstrap SDK runtime build invokes the stage0 Swift driver, which expects lld-link beside the staged tools. Copy the pinned runtime and cmark DLLs into the image so downstream bootstrap steps can run tools by absolute path. (cherry picked from commit 8cbe68a)

Introduce Build-SDK for staged SDK construction, and use it to build the Bootstrap SDK with the stage0 compiler. The bootstrap SDK keeps the surface needed by the next compiler stage without building Foundation, XCTest, Testing, or the full distribution supplemental set. (cherry picked from commit 289f920)

Add the second Windows bootstrap compiler cache and build stage1 with the stage0 compiler against the Bootstrap SDK. Stage1 expands the target set and keeps the tools needed by downstream SDK builds, including lld, the autolink driver, llvm-ar, llvm-ranlib, and the SwiftSyntax DLLs needed by the staged compiler. Install it under its own project cache so stage0 and stage1 cannot pollute each other. (cherry picked from commit d81f0bd)

Build the host SDK image with the stage1 compiler before configuring the stage2 compiler and toolchain consumers. This gives the self-hosting compiler a staged SDK produced by the previous compiler stage instead of relying on the pinned toolchain SDK for the rest of the build. (cherry picked from commit 7fad743)

Use the stage1 compiler and staged host SDK to build the stage2 compiler. Then build the host toolchain components against that same SDK. The host dynamic SDK slice can be reused by the later distribution SDK pass, keeping the self-hosted build from creating a second independent host runtime image. (cherry picked from commit 034a158)

Replace the experimental-only SDK helper with the generic Build-SDK path for staged SDK builds. This removes duplicated runtime, overlay, and SDK construction logic so the bootstrap, host, and distribution SDK phases share the same builder. (cherry picked from commit 3456fcc)

Remove the legacy SDK selection and version plumbing now that the staged SDK builder produces the platform SDK directly. Keep package-manager runtime, runtime packaging, and SDK installation consumers on the canonical platform SDK layout instead of a separate Toolchain or Experimental image. (cherry picked from commit f7d8d9e)

When CMake configures Android builds, it may auto-detect the NDK clang as the target compiler. Sending that compiler through clang-cache.exe from the staged Windows toolchain can mix LLVM versions. That version skew makes dependency scanning look for builtin headers in the wrong resource directory. Skip the launcher for Android SDK builds while keeping caching for paths that use the staged compiler directly. (cherry picked from commit 0fb741a)

The staged compiler table carries MSVC-style clang-cl entries in .C/.CXX and GNU-style clang entries in .GNUC/.GNUCXX. Select the GNU drivers for non-Windows SDK dependencies, compiler-rt, and dispatch so Android builds do not receive MSVC-only flags such as /GS- and /Gw. (cherry picked from commit 209d3c8)

Build Android swift-inspect with a target-aware compiler view that exposes the stage1 GNU clang drivers under .C/.CXX. This keeps the NDK clang from seeing MSVC-style flags while still using the stage1 Swift compiler and Android SDK. (cherry picked from commit fc7c61c)

Add Set-WindowsManifestDependencies to merge dependency entries into an embedded manifest and re-embed it with mt. This gives later SxS binding steps a shared path for binding tools without replacing unrelated manifest content. (cherry picked from commit 5450656)

Stage each Swift runtime DLL needed by the laid-out toolchain as a private per-DLL SxS assembly under usr/bin. Compute each EXE's static import graph and write the full Swift runtime closure into the EXE's application manifest. Disable linker-generated DLL manifests for Swift's CMake-built DLLs and for the mimalloc MSBuild project, then validate existing DLL manifest resources before binding: reject UAC execution-level metadata and unexpected reserved RT_MANIFEST resource IDs so implicit linker manifests cannot poison SxS activation. Keep the checked-in WiX authoring canonical and warn when the live import graph drifts from bld/cli/dbg/ide package ownership. (cherry picked from commit a4c76ff)

Build the Stage2 test-time tools needed by check-swift before the final test build. Bind the runtime-loading EXEs to the platform SDK runtime they are tested against. Use the build-host architecture so host-run tools remain runnable when the final toolchain target differs. Keep this separate from the distribution SxS pass because these tools execute from the build tree. (cherry picked from commit 7249c26)

Run the dispatch, XCTest, and llbuild test builds with the Stage1 compiler artifacts instead of the legacy Compilers cache. The swift-format and SourceKit-LSP SwiftPM tests also need SwiftSyntax from the Stage2 compiler build, matching the CMake build rules for those projects. Use the Stage2 host library path there and fix the stale swift-markdown CAtomic include path in the SourceKit-LSP test arguments. (cherry picked from commit c68327f)

Disable dispatch in the Windows bootstrap compiler caches. Stage0 and Stage1 do not build SourceKit or the runtime SDK, so they do not need Swift's Libdispatch.cmake path to configure nested libdispatch ExternalProjects. Keep passing the staged DynamicCDispatch package to the Stage2 compiler build, where SourceKit and tool components still need host dispatch. Drop the Stage0CDispatch build and stop feeding dispatch packages to Stage0 and Stage1. (cherry picked from commit 3c71b48)

When cross-compiling the NoAsserts toolchain, we would no copy the mimalloc into the staged NoAsserts toolchain. This would break the packaging as that expects to find the dependency for distribution. (cherry picked from commit 659990e)

This simplifies the use of the script: `-Toolchain`: build the toolchain (default) `-Windows`: build the Windows SDK (opt-in) `-Android`: build the Android SDK (opt-in) `-Package`: package the toolchain (opt-in) (cherry picked from commit 4c0fa34)

We now have the early swift driver + bootstrapping. At this point, everything that is needed to enable WMO is available. Restore the optimization when building the toolchain to avoid unnecessary pessimisation. (cherry picked from commit 2115df5)

Runtime clients of swiftCore need the SwiftRT image-registration object on their link lines. On COFF this object supplies pSwiftImageConstructor and the .sw5* section range symbols used to register Swift metadata and conformances for each image. CMake propagates usage requirements when an OBJECT library appears in an INTERFACE_LINK_LIBRARIES chain, but it does not add that object's payload to the final consumer link line. Keep the swiftrt targets in the interface for their usage requirements, and explicitly propagate their object files with TARGET_OBJECTS. (cherry picked from commit e86c870)

Allow non-Darwin compiler builds to consume an already-built libdispatch package instead of always creating a nested ExternalProject. When dispatch_DIR is set, import the dispatch package and use it for the host SDK dispatch target. Continue building libdispatch for other non-Darwin target SDKs so cross-compilation still gets target-specific dispatch variants. (cherry picked from commit 604bc52)

When %host-build-swift builds plugin DLLs on Windows, those DLLs are loaded by the compiler under test. Pass the configured host SDK and resource directory so the plugins link against the runtime that compiler will load instead of the Stage2 stdlib resources. (cherry picked from commit fc6d841)

compnerd · 2026-06-09T16:36:16Z

@swift-ci please test macOS platform

compnerd · 2026-06-09T21:25:29Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-10T21:38:48Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531
swiftlang/llvm-project#13184

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-11T16:02:16Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-12T15:38:44Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

(cherry picked from commit 548f23c)

compnerd · 2026-06-12T17:51:53Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-12T17:51:57Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please smoke test

compnerd · 2026-06-13T06:25:24Z

@swift-ci please test Windows platform

compnerd · 2026-06-14T02:29:08Z

@swift-ci please test

compnerd · 2026-06-14T02:29:24Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-14T18:45:45Z

Please test with following PRs:
swiftlang/swift-installer-scripts#531

@swift-ci please build toolchain Windows platform

compnerd · 2026-06-14T18:45:54Z

@swift-ci please test Windows platform

…test PATH (cherry picked from commit 4d6257a)

compnerd · 2026-06-15T15:44:28Z

@swift-ci please smoke test

compnerd · 2026-06-15T15:44:39Z

@swift-ci please test

compnerd · 2026-06-16T00:05:59Z

@swift-ci please test Windows platform

charles-zablit · 2026-06-16T05:41:50Z

The windows tests are still failing with the exact same lldb tests as swiftlang/llvm-project#13212
Yet, the tests pass on top of tree 6.4.x.

I'm working on #89967 to fix this.

charles-zablit · 2026-06-16T13:23:16Z

********************
Unresolved Tests (1):
  lldb-api :: lang/swift/explicit_modules/implicit_fallback/TestSwiftExplicitModulesImplicitFallback.py

********************
Failed Tests (3):
  lldb-api :: lang/swift/foundation_value_types/data/TestSwiftFoundationTypeData.py
  lldb-api :: lang/swift/foundation_value_types/date/TestSwiftFoundationTypeDate.py
  lldb-api :: lang/swift/foundation_value_types/uuid/TestSwiftFoundationTypeUUID.py

charles-zablit · 2026-06-16T13:23:30Z

swiftlang/llvm-project#13208

@swift-ci please test windows

charles-zablit · 2026-06-16T16:06:24Z

swiftlang/llvm-project#13220

@swift-ci please test Windows

compnerd and others added 28 commits June 5, 2026 12:05

utils: rename Build-SDK to Build-LegacySDK

522df84

This is preparatory work to allow us to build multiple "experimental"-style SDKs for bootstrapping. (cherry picked from commit 995cfa2)

utils: avoid re-cloning the sources for EarlySwiftDriver

b4744d3

We already have a checkout for the dependencies of early-swift-driver. Reuse the existing sources rather than checking them out from git again. (cherry picked from commit f230c75)

utils: remove -TraceExpand argument for build.ps1

e3b65d4

(cherry picked from commit f6e4c72)

utils: silence output of New-Item

df16913

(cherry picked from commit 06c0608)

compnerd requested a review from a team as a code owner June 5, 2026 19:48

compnerd requested a review from DougGregor June 5, 2026 19:49

[windows] stabilize lldb test runtime resolution

43bf616

(cherry picked from commit 548f23c)

[windows] prefer the SDK runtime over the flat build bin on the lldb …

b9eec22

…test PATH (cherry picked from commit 4d6257a)

charles-zablit mentioned this pull request Jun 16, 2026

windows: enable bootstrapping #89988

Closed

charles-zablit mentioned this pull request Jun 16, 2026

TestSwiftExplicitModulesImplicitFallback runs into the MAX_PATH limit on Windows swiftlang/llvm-project#13219

Open

eeckstein approved these changes Jun 17, 2026

View reviewed changes

eeckstein changed the title ~~windows: enable bootstrapping~~ [6.4] windows: enable bootstrapping Jun 17, 2026

eeckstein requested a review from etcwilde June 17, 2026 09:38

charles-zablit linked an issue Jun 17, 2026 that may be closed by this pull request

winget update Swift.Toolchain does not uninstall the old version of the toolchain #88384

Closed

al45tair approved these changes Jun 17, 2026

View reviewed changes

compnerd merged commit c2c4064 into swiftlang:release/6.4.x Jun 17, 2026
6 checks passed

compnerd deleted the bootstrapping64 branch June 17, 2026 15:43

Conversation

compnerd commented Jun 5, 2026 • edited by eeckstein Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

compnerd commented Jun 9, 2026

Uh oh!

compnerd commented Jun 9, 2026

Uh oh!

compnerd commented Jun 10, 2026

Uh oh!

compnerd commented Jun 11, 2026

Uh oh!

compnerd commented Jun 12, 2026

Uh oh!

compnerd commented Jun 12, 2026

Uh oh!

compnerd commented Jun 12, 2026

Uh oh!

compnerd commented Jun 13, 2026

Uh oh!

compnerd commented Jun 14, 2026

Uh oh!

compnerd commented Jun 14, 2026

Uh oh!

compnerd commented Jun 14, 2026

Uh oh!

compnerd commented Jun 14, 2026

Uh oh!

compnerd commented Jun 15, 2026

Uh oh!

compnerd commented Jun 15, 2026

Uh oh!

compnerd commented Jun 16, 2026

Uh oh!

charles-zablit commented Jun 16, 2026

Uh oh!

charles-zablit commented Jun 16, 2026

Uh oh!

charles-zablit commented Jun 16, 2026

Uh oh!

charles-zablit commented Jun 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

compnerd commented Jun 5, 2026 •

edited by eeckstein

Loading