Windows build fails and the nightly compiler crashes lowering Kernel Completion

[coenttb]

Problem

swift-kernel does not compile on Windows, and crashes the compiler on the 6.4.x and main nightly toolchains. Neither is visible from this repository's recent runs, because they were push-event runs: the Windows and main-nightly legs were skipped, and the 6.4.x-nightly leg is advisory there. The failures surfaced in a full-tier workflow_dispatch run of a downstream consumer.

1. Windows (Swift 6.3, debug) — source error

Sources/Kernel File/Kernel.File.Clone.Error+code.swift:34:31: error: type 'Error.Code' has no member 'POSIX'

Ten instances, in Kernel.File.Clone.Error+code.swift (lines 34, 37, 40, 41, 44, 47, 50) and Kernel.File.Direct.Error+code.swift (lines 38, 41, 44). The POSIX member of Error.Code appears not to exist on the Windows platform leg.

2. Ubuntu, Swift 6.4.x nightly and Swift main nightly (release) — compiler crash

swift-frontend: /home/build-user/swift/lib/SILGen/SILGenLValue.cpp:3203:
LValue SILGenBorrowedBaseVisitor::getLookupExprBaseLValue(LookupExpr *, AccessSemantics,
SGFAccessKind, LValueOptions, AccessStrategy &): Assertion `!e->getType()->is<LValueType>()' failed.

3. While evaluating request ASTLoweringRequest(Lowering AST to SIL for module Kernel_Completion)
Build config: +assertions
*** Program crashed: Aborted ***  (signal 6)

The nightly containers are the fleet's assertions-enabled compilers, so this is a SIL-validity signal against Kernel Completion sources rather than a nightly flake. It reproduces on both nightly legs.

Evidence

Full-tier workflow_dispatch run of swift-foundations/swift-application, which reaches swift-kernel transitively through swift-environment:
https://github.com/swift-foundations/swift-application/actions/runs/30629823992

Windows job log carries the ten Error.Code errors; both nightly job logs carry the SILGen assertion. Every other leg of that run is green, and the consumer package contributes no code to either failure — the build never reaches it.

For contrast, this repository's own most recent main run (https://github.com/swift-foundations/swift-kernel/actions/runs/30629349263, head 64a70679) concluded success with Windows, macOS, and main-nightly skipped — a push-tier result, not full-tier coverage.

Proposed outcome

Both legs build: a full-tier workflow_dispatch run of swift-kernel at head with Windows green and the two nightly legs green (or, for the nightly crash, an isolated reproducer filed against the toolchain and the source shape adjusted so lowering succeeds).

Observable: the same downstream full-tier run above goes green on Windows and both nightly legs without changes to the consumer.

Compatibility and migration impact

Windows currently cannot build at all, so no working Windows consumer can regress. The nightly crash blocks the assertions-enabled SIL gate for every package whose closure includes Kernel Completion.

[coenttb]

(1) Windows — fixed in ef4610f. (2) Nightly crash — toolchain defect, reproduced and recorded.

Windows: the import was not the cure

Error.Code.POSIX is owned by ISO 9945 Core, and swift-windows does not depend on it — the namespace is not merely un-imported on that leg, it is absent from the Windows build graph entirely. So adding an import would fail with "no such module".

Nor should it be imported: Win32 codes are not POSIX codes, so the POSIX table has nothing correct to say about them. Kernel.File.Clone.Error+Windows.swift already states this — it transliterates an already-classified semantic error from its Win32 owner precisely because "kernel's own init(code:operation:) cannot classify them". Classifying here as well would have grown a second, competing Windows mapping.

Both initializers keep their cross-platform signatures and carry the code through as .platform on Windows. Kernel.File.Copy.swift already carries this exact #if os(Windows) shape, so this follows a realized in-repo precedent rather than inventing one. Confirmed no caller loses anything: on Windows nothing calls either init(code:operation:) — the only callers are the Darwin and Linux bridges, both platform-gated.

Windows sweep: evidence, not eyeballing

Rather than reviewing 33 Windows-gated files by hand, I pulled the Windows job log from your linked run (job 91153461555) and grouped every diagnostic:

Count	File	Message
70	Kernel.File.Clone.Error+code.swift	type 'Error.Code' has no member 'POSIX'
30	Kernel.File.Direct.Error+code.swift	type 'Error.Code' has no member 'POSIX'

100 error lines, zero from anywhere else. The log also shows Kernel_Event, Kernel_Completion, Kernel_Thread and the rest of Kernel_File compiling cleanly on Windows. No sibling drift remains on that leg.

(2) Nightly crash: reproduced, minimized, recorded as a toolchain defect

Your read was right — not a flake. I reduced it to 33 dependency-free lines and reproduced it on both nightlies locally, on macOS/arm64, which rules out anything container- or Linux-specific:

Toolchain	Result
Swift 6.3.3 release	compiles clean, exit 0
Swift 6.4-dev (6.4.x-snapshot-2026-07-23)	assertion, exit 6
Swift 6.5-dev (main-snapshot-2026-07-11)	assertion, exit 6

Trigger: calling a mutating method through a member whose accessor is nonmutating _modify, where the base of that member is the yield of a mutating _read coroutine on a get-only property. The nonmutating _modify needs only a borrow, so SILGen takes the borrowed-base path and finds an lvalue base — which the assertion forbids. In this package that is uring.next.entry.<mutating method>(…) in enqueue(_:target:); the reduction drops the switch, the extension, the enum and the borrowed argument, none of which are needed.

Two knobs, each necessary — and the second is the interesting one:

• Plain (non-mutating) _read on next → compiles clean on 6.4-dev.
• Plain _modify on entry → the crash is replaced by a legitimate diagnostic: cannot use mutating member on immutable value: 'next' is a get-only property.

Uring.next really is get-only. Writing through it is accepted only because Slot.entry is nonmutating _modify. Whether that composition should be accepted or diagnosed is a genuine design question — but asserting is wrong either way, and the shape is the whole point of the Slot design (write straight through a stored pointer into mmap'd memory, no write-back). I did not contort the source to dodge it, since any workaround would trade a compiler bug for a design regression in the submission path.

Recorded internally as swift-institute/Issues#87 (no existing record covered it — I searched SILGenLValue, getLookupExprBaseLValue and SILGenBorrowedBaseVisitor). Upstream stays principal-gated per the standing ruling on Issues#58. Both nightly legs stay red pending toolchain disposition — that is not a source defect in this repository and no source change here will clear it.

Full-tier evidence at the previous head

Your dispatched run 30630099158 (head 64a7067) failed on exactly three legs — Windows, 6.4.x nightly, main nightly — and was green everywhere else, including macOS 6.3, Ubuntu 6.3, tvOS/watchOS simulators, DocC, SwiftLint, swift-format and swift-linter. So this repository's non-nightly full-tier surface is already clean; ef4610f is aimed at the one remaining source failure.

Commit. ef4610f

Push run. https://github.com/swift-foundations/swift-kernel/actions/runs/30631711519

Expected disposition of the next full tier: Windows green, everything green except the two nightly legs, which remain blocked on Issues#87.

[coenttb]

Windows-leg result from full-tier CI run https://github.com/swift-foundations/swift-kernel/actions/runs/30637005244 (head ef4610f, workflow_dispatch), job ci / matrix / Windows (Swift 6.3, debug): https://github.com/swift-foundations/swift-kernel/actions/runs/30637005244/job/91177145245

Setup and toolchain install succeeded; the Test step started at 14:05:30Z and never completed — it ran ~44 minutes before the job was cancelled at 14:49:17Z, with the runner's cleanup step reaping orphaned swift-frontend/swiftc/git processes (pid-reuse warnings across dozens of stale compiler subprocesses). This reads as a hang, not the clean 6.3.3-release compile #87's own reproduction matrix would predict (that assertion reproduces only on 6.4-dev/6.5-dev nightly toolchains, not the 6.3 release toolchain this leg runs) — flagging that mismatch rather than asserting the same root cause.

Leaving this open, blocked on swift-institute/Issues#87 per the recorded disposition, since the nightly-toolchain crash investigation is the active thread for compiler-side kernel-completion lowering defects and this leg's hang has not been independently triaged yet.