Track the next-release migration from Windows GNU/MinGW to native MSVC

[LunaStev]

Target release: the next release. Goal: supported Windows compiler hosts and generated programs use MSVC on amd64 and ARM64, and active Windows build/release/runtime paths no longer require GNU/MinGW.

Audit baseline: master 3950416e, 2026-09-12. This is a migration plan based on current code and existing reports, not a claim that every validation gap is a reproduced compiler bug.

Explicit MSVC targets, COFF linking, and transactional DLL/import-library/PDB publication already exist. Native ARM64 host CRT/message ownership was repaired in #493. Remaining work spans native amd64 host provisioning, reliable SDK/runtime resolution, executable ABI proof, and release independence. Building the compiler with MSVC alone is not completion: the current Windows output default is GNU.

This tracker coordinates focused work; it does not duplicate the original host-build report #292, output-target umbrella #498, or Windows provider umbrella #385. The earlier instruction in #498 to retain GNU applies while prerequisites are being built. The new release goal authorizes a final removal only after the gates below pass.

Difficulty is an estimate of ABI/runtime risk and required expertise, not a severity label. The five very-high tasks involve native executable evidence across calling conventions, startup, stack behavior, or module ownership; some correct code may only need stronger tests. First-contribution tasks have bounded scope and no ABI redesign.

First contributions

• Include enabled MSVC targets in existing system-ABI and std-net codegen regressions #627 — Include enabled MSVC targets in existing system-ABI and std-net codegen regressions
• Add table-driven tests for the MSVC default-library and linker-option builder #628 — Add table-driven tests for the MSVC default-library and linker-option builder
• Include lld-link in the Windows MSVC package tool inventory #629 — Include lld-link in the Windows MSVC package tool inventory

Medium difficulty

• Support MSVC linker response files for long and Unicode input paths #620 — Support MSVC linker response files for long and Unicode input paths
• Make Windows package dependency inspection fail on missing tools and unreadable PE files #622 — Make Windows package dependency inspection fail on missing tools and unreadable PE files
• Run the full Windows case suites with explicit native MSVC output targets #623 — Run the full Windows case suites with explicit native MSVC output targets
• Gate MSVC releases on extracted-package execution with a controlled Windows environment #624 — Gate MSVC releases on extracted-package execution with a controlled Windows environment
• Switch native Windows default Wave output to MSVC after native validation passes #625 — Switch native Windows default Wave output to MSVC after native validation passes

High difficulty

• Build the native Windows amd64 compiler with MSVC and a verified LLVM dependency set #612 — Build the native Windows amd64 compiler with MSVC and a verified LLVM dependency set
• Resolve a coherent Windows SDK and VC library set for MSVC output targets #613 — Resolve a coherent Windows SDK and VC library set for MSVC output targets
• Validate MSVC COFF objects and archive members before invoking the linker #614 — Validate MSVC COFF objects and archive members before invoking the linker
• Stage native MSVC release packages for amd64 and ARM64 without MinGW runtimes #621 — Stage native MSVC release packages for amd64 and ARM64 without MinGW runtimes
• Remove Windows GNU and MinGW support after the MSVC release gates pass #626 — Remove Windows GNU and MinGW support after the MSVC release gates pass

Very high difficulty

• Establish executable MSVC x64 C ABI interoperability in both call directions #615 — Establish executable MSVC x64 C ABI interoperability in both call directions
• Establish executable Windows ARM64 MSVC C ABI interoperability #616 — Establish executable Windows ARM64 MSVC C ABI interoperability
• Validate hosted MSVC startup and generated runtime-helper dependencies #617 — Validate hosted MSVC startup and generated runtime-helper dependencies
• Verify MSVC stack probing and Windows unwind metadata for generated Wave functions #618 — Verify MSVC stack probing and Windows unwind metadata for generated Wave functions
• Complete native MSVC DLL loading, C exports and allocator-ownership interoperability #619 — Complete native MSVC DLL loading, C exports and allocator-ownership interoperability

Reuse existing work

• Native host/output foundations: Windows Native Support (MSVC) #292 and Generate and link native Windows MSVC programs for amd64 and ARM64 #498. Native ARM64 blockers: Restore Windows ARM64 case builds when static CRT linking cannot locate psapi #608 (psapi library resolution), Fix native Windows ARM64 compiler stack overflow on the executor restart fixture #609 (compiler stack overflow before executor execution).
• Tooling and failure visibility: Find MSVC Cargo build outputs in the Wave case runner #499 (MSVC compiler discovery, good first issue), Run independent native ARM64 tests even when codegen diagnostics fail #575, Propagate required tool-probe failures from native ARM64 diagnostics #579, Recover native ARM64 crash evidence when LLDB stalls on the imported fixture #581, Collect all case precheck failures without suppressing native execution and reports #610. General case report identity is Include target and suite identity in Wave case JSON reports #462; negative-result correctness is Preserve actual exit codes and failure reasons in Wave case JSON reports #576/Reject compiler failures in cases that expect a nonzero program exit #577. Do not recreate these tickets under new Windows titles.
• Windows filesystem correctness: Preserve and classify native Windows filesystem errors #523, Return real handle metadata from Windows fstat #524, Use Unicode Windows APIs for UTF-8 filesystem paths #525, Honor append and truncate flags in native Windows file opening #527, Do not report every existing Windows path as accessible for every mode #528, Distinguish Windows drive-relative, rooted and UNC paths in path_is_abs #529. Windows environment encoding: Convert the Windows environment block to UTF-8 instead of copying narrow API bytes #526.
• Native process/handle support: Add native Windows process spawning and waiting APIs #429, Implement Windows anonymous pipes and handle duplication #430, Implement Windows console raw-mode support #431 and Stop guessing between HANDLE and SOCKET by trying CloseHandle first #568, coordinated by Track remaining Windows std::sys provider work #385. Event/IOCP follow-ups: Prevent low-index sockets from starving Windows event_wait results #530 and Bound IOCP staging allocations independently of caller buffer capacity #534. Retain the already-added Keep live sockets usable across task executor shutdown and restart on Windows #531 executor restart regression; its current native ARM64 compiler blocker is Fix native Windows ARM64 compiler stack overflow on the executor restart fixture #609.
• Contributor documentation: Document the exact Wave target support and validation matrix #401 (target matrix) and Add a standard-library system capability matrix #378 (std capability matrix). Update these existing documents/issues as the migration lands; their old target-status statements must be checked against the actual implementation.

Provider gaps are existing Windows correctness work, not evidence that changing the Rust toolchain fixes them. Native MSVC execution must cover the APIs advertised for this release. Broader new platform APIs can remain separate follow-up work when they are not required for that supported surface.

Order and release gates

1. Land independent first-contribution checks and native host/SDK/dependency foundations. Resolve Restore Windows ARM64 case builds when static CRT linking cannot locate psapi #608/Fix native Windows ARM64 compiler stack overflow on the executor restart fixture #609. Keep GNU usable during this stage.
2. Complete native x64/ARM64 ABI, ordinary startup, DLL and large-frame/unwind validation. Extend the full existing case suites to explicit MSVC execution without deleting or duplicating their workloads.
3. Build native MSVC release archives, validate extracted artifacts in controlled Windows environments, and switch the native default only once required execution gates pass.
4. Remove Windows GNU registrations, fallback/discovery code, CI provisioning and package inputs in the final retirement issue. Unsupported old triples get actionable migration errors. Gate release on MSVC-only Windows results.

Exit criteria:

• Both compiler host architectures and generated program architectures are verified as native, and the enabled LLVM backends are explicit.
• Native cases and ABI/runtime checks pass; skipped execution or object-only success does not substitute for required native results.
• The distributed compiler/tools and ordinary generated programs work with the stated Windows prerequisites, with no MinGW payloads or hidden GNU runtime/tool dependencies.
• No silent fallback to GNU occurs, and the active Windows target list/build/release paths are MSVC-only after cutover.
• Preserve non-Windows GNU support and Linux LoongArch64. Preserve meaningful tests by adapting them before removing obsolete harness paths.
• Continue using native Windows OS APIs in std/sys; this migration does not authorize replacing those providers with libc wrappers. Compiler/LLVM CRT dependencies are handled separately from the Wave standard-library API layer.

Each child issue owns an independently reviewable outcome with evidence, completion criteria and dependencies. This task creates issues only; implementation and release cutover happen in subsequent work.