_Lock Test Process (Windows branch): Kernel.Descriptor construction uses the wrong init label/type

[coenttb]

Problem

Tests/Support/_Lock Test Process/main.swift's Windows branch (#else at the bottom of the file) constructs the lock descriptor as:

descriptor: Kernel.Descriptor(rawValue: handle),

where handle is the HANDLE returned by CreateFileW. On Windows, Kernel.Descriptor resolves (via swift-kernel's Kernel = Windows.Kernel typealias → swift-windows's Windows.Kernel.Descriptor typealias) to Windows.\32`.Kernel.Descriptorinswift-microsoft/swift-windows-32`. That type's only public constructor is:

public init(_rawValue: UInt)

— label _rawValue, not rawValue, and it takes UInt, not HANDLE. This is a call-site defect against an existing, stable L2 API — not a capability gap — so it belongs here rather than on the Windows owner. The POSIX branch of the same file (line 253) already calls the equivalent correctly: Kernel.Descriptor(_rawValue: rawFd).

This is a second, independent compile-time defect in the same helper file's Windows branch, distinct from the Kernel.Lock.Kind / .Range / .Token / extended-.Error capability gap tracked at swift-microsoft/swift-windows-32#9. It surfaces once that gap is closed and the Windows branch compiles far enough to reach this call.

Observable outcome

The Windows branch's descriptor construction becomes:

descriptor: Kernel.Descriptor(_rawValue: UInt(bitPattern: handle)),

(or the ecosystem's canonical HANDLE → UInt bit-pattern conversion, if composition/swift skill guidance names a different owner for that conversion — worth a quick check before landing, since a bespoke UInt(bitPattern:) at a call site is exactly the kind of reach-through the composition skill flags). A subsequent full-tier Windows (Swift 6.3, debug) CI run at swift-foundations/swift-kernel gets past this line once swift-microsoft/swift-windows-32#9 has landed and this fix is applied together with it — this issue alone does not turn the Windows leg green, since the Kind/Range/Token/Error gap still blocks compilation upstream of this line.

Scope note

Institute Work Project admission (i.e., whether this lands as scheduled/prioritized work) is a separate coordinator decision from this issue's filing.

Cross-references

• Diagnosed from Complete the hoist inside kernel: Completion imports, platform-bridge retags, affinity dispatch (D1/D2) #6 (comment 5144909781) during the assessment lane's read of Tests/Support/_Lock Test Process/main.swift at main 0ff2900.
• Companion issue (the larger capability gap, blocking upstream of this line): Feature: implement the full Kernel.Lock contract (Kind, Range, Token, extended Error cases) to match ISO_9945.Kernel.Lock swift-microsoft/swift-windows-32#9.

[coenttb]

Dispatch claim: fix lane dispatched by the Swift Institute coordinator session 9b789e8f (2026-07-31 evening watch). Scope: this issue plus classification of the Windows-gated Clock.*.now sites in this repository against the file-level import class recorded at swift-microsoft/swift-windows-32#11.

[coenttb]

Fix landed: b8d13d3 on main

Pushed to swift-foundations/swift-kernel main (0ff2900..b8d13d3), three files, explicit pathspecs:

1. The issue's fix. Tests/Support/_Lock Test Process/main.swift:412 (Windows branch): Kernel.Descriptor(rawValue: handle) → Kernel.Descriptor(_rawValue: UInt(bitPattern: handle)), matching the ecosystem's established HANDLE→UInt bit-pattern conversion idiom used throughout swift-windows-32 (e.g. Windows.Kernel.Descriptor(_raw: UInt(bitPattern: handle)) in Windows.Kernel.swift, Windows.Kernel.Pipe.swift, Windows.Kernel.Process.Spawn.swift, etc.), and the correct public initializer init(_rawValue: UInt) on Windows.32.Kernel.Descriptor.

2. Kernel Lock and Kernel Time reference Clock.*.now without importing Windows_32_Kernel_Clock — consumer Windows builds fail at main (3d9e83d0) swift-microsoft/swift-windows-32#11-class sweep of the three candidate files:

   • Sources/Kernel Thread/Kernel.Lock.Acquire+timeout.swift — in-class. Its #if gate (os(macOS) || … || os(Windows)) includes Windows, and it calls Clock.Continuous.now (line 20). Tracing manifest reachability: Kernel Core's exports.swift @_exported public imports POSIX_Kernel on POSIX (which itself @_exporteds POSIX_Kernel_Clock, supplying .now) but only Windows_Kernel + Windows_Kernel_Process on Windows — no Windows Clock module at all, so .now was unreachable on Windows for every target depending on Kernel Core (not just this file). This is the same cross-module Clock-visibility class as #11, one layer up (umbrella export, not a single leaf file). Fixed by adding Windows_Kernel_Clock as a Kernel Core dependency in Package.swift and @_exported public import Windows_Kernel_Clock in Sources/Kernel Core/exports.swift, mirroring the existing POSIX_Kernel_Clock re-export.
   • Sources/Kernel Event/Kernel.Event.Source+Kqueue.swift — not in-class. Whole file is gated #if !os(Windows) (exclusion); the Clock.Continuous.now references are never on the Windows compilation path.
   • Sources/Kernel Event/Kernel.Event.Source+Epoll.swift — not in-class, same reasoning (#if !os(Windows) then #if os(Linux)).

Verified locally: workspace package build --package-path . --jobs 6 (fresh, no cache) — full package Build complete! on macOS, zero errors (only pre-existing #StrictMemorySafety warnings, unrelated).

CI evidence: run 30666368621 (full-tier workflow_dispatch at b8d13d3)

https://github.com/swift-foundations/swift-kernel/actions/runs/30666368621 — overall conclusion failure. Non-green legs, each named and attributed:

• Windows (Swift 6.3, debug) — cancelled. Started 21:24:12Z, last progress (diagnostics) at 21:40:20Z, force-cancelled at 22:09:19Z (The operation was canceled.) — a ~29 min silent hang after compilation output stopped, matching the Windows 6.3.3 release: SwiftPM fails to terminate after compilation, orphaned swift-frontend/swiftc processes, 31-44 min hang to force-cancel swift-institute/Issues#89 SwiftPM-teardown non-termination signature (cited by attribution, not as a blocker). Compilation reached and passed both fixed sites with zero errors on either: no Kernel.Descriptor init-label diagnostic, no Clock.*.now diagnostic. The only diagnostics present (4, all at main.swift:409 and :411) are 'Token' is not a member type of enum 'Kernel.Kernel.Lock' / type 'Kernel.Lock' has no member 'Token' — this is the pre-existing, already-tracked upstream capability gap at Feature: implement the full Kernel.Lock contract (Kind, Range, Token, extended Error cases) to match ISO_9945.Kernel.Lock swift-microsoft/swift-windows-32#9 (Kind/Range/Token/Error), resolved at swift-windows-32 commit d3cc090 (per this run's "Working copy of … resolved at main (d3cc090)" line). Not a regression from this change; expected per this issue's own "Observable outcome" section.
• Ubuntu (Swift 6.4.x nightly, release), Ubuntu (Swift 6.3, release), Ubuntu (Swift main nightly, release) — failure. All three fail identically and immediately at the test step (shell: sh -e {0} running FILTER_ARGS=(--filter "$FILTER")): Syntax error: "(" unexpected (expecting "fi"). This is a pre-existing CI workflow defect — bash array syntax executed under sh/dash, not a Swift compile error — unrelated to this commit's content and outside this lane's authority (workflow-file edits are forbidden here). Reporting for the owning surface to address.
• ci / matrix / ci-ok, ci / ci-ok — failure (gating aggregation of the above: windows-release selected-but-cancelled, linux-release selected-but-failed).

All other legs (macOS, iOS/tvOS/watchOS/visionOS Simulators, SwiftLint, swift-linter, swift-format lint, DocC archive, advisory legs) — success.

Not closing this issue — leaving closure to the coordinator's own run read.

[coenttb]

Correction + swept finding on the remaining Token errors

Checked the coordinator's read against the actual export graph before acting — the Token gap is not the same class as the Clock fix, and the instructed fix (a direct swift-windows-32 package dependency in swift-kernel) would create a new defect: it contradicts this repo's own documented layering rule.

Why Clock and Lock are different shapes:

• Clock: swift-kernel (L3-unifier) → swift-windows's Windows Kernel Clock product (L3-policy peer, already exists, @_exported public import Windows_32_Kernel_Clock) → L2. Kernel Core simply wasn't importing that existing L3-policy product. Fixed by adding the swift-windows product dependency — no new package dependency, no layer skip.
• Lock/Token: no Windows Kernel Lock product exists in swift-windows at all (Package.swift products: Kernel, Kernel Descriptor, Kernel Socket, Kernel Clock, Kernel File, Kernel Thread, Kernel Process, Test Support — no Lock). The only thing swift-windows has is Sources/Windows Kernel/Windows.Kernel.Lock.swift, a bare public typealias Lock = Windows.\32`.Kernel.Lock, whose own doc comment states the L2-canonical form is "carried by the Windows 32 Kernel umbrella this target already re-exports" — i.e. swift-windows's own code *assumes* Windows_32_Kernel(the L2 umbrella) re-exportsWindows_32_Kernel_Lock`'s members.

Root cause, upstream, exact location: swift-microsoft/swift-windows-32, Sources/Windows 32 Kernel/exports.swift. Its target already manifest-depends on "Windows 32 Kernel Lock" (Package.swift line 314), but the file's @_exported public import list omits Windows_32_Kernel_Lock (it exports Clock/Console/Core/Directory/Environment/File/IO/Memory Map/Process/Socket/System/Thread/Time — Lock and Terminal are both absent despite Terminal also being a declared target dependency). That omission is what breaks the re-export chain swift-windows's Windows.Kernel.Lock.swift relies on, and it's a swift-windows-32 in-repo fix (their own umbrella target, already declares the dependency, just needs the @_exported import line) — the same shape of fix as this repo's Clock fix, just one repository up.

Why I did not add Windows_32_Kernel_Lock directly to swift-kernel: Sources/Kernel/Exports.swift in this repo documents the composition rule explicitly (Descriptor-chain comment, [PLAT-ARCH-005]/[PLAT-ARCH-008e]): "L3-unifier composes its peer L3-policy tier; never reaches across into L2." Adding a raw swift-windows-32 package dependency to swift-kernel to reach Windows_32_Kernel_Lock directly would violate that documented rule in this exact repo, and would be inconsistent with every other Windows product this repo consumes (all via swift-windows, never swift-windows-32 directly). This is out of my authority twice over: the correct fix is an edit to swift-microsoft/swift-windows-32's exports.swift (a different repository — mutations there are forbidden for this lane), and the workaround the alternative would require (skip-layer dependency) would knowingly introduce an architecture violation in swift-kernel.

Sweep of the same predicate (Windows-path member visibility) in swift-kernel: beyond Clock (fixed) and Lock/Token/Kind/Range/Error (blocked upstream, same root cause, no new module), no other Windows-gated reference in this repo hits an unimported member-supplying module — Descriptor, Socket, Process, Thread, File each already have a dedicated Windows Kernel X product from swift-windows correctly @_exported-imported by Kernel/Exports.swift or Kernel Core/exports.swift. Kernel.Lock usage in this repo is confined to Sources/Kernel Thread/Kernel.Lock.Acquire+timeout.swift, Sources/Kernel Core/Kernel.Failure.swift, Tests/Support/_Lock Test Process/main.swift, and Tests/Kernel Tests/Kernel.Lock.Integration Tests.swift — all downstream of the same single upstream gap, not independent defects.

Recorded blocker: the Windows leg's 4 remaining Token diagnostics at main.swift:409/411 cannot be cleared from within swift-foundations/swift-kernel. Owning fix: swift-microsoft/swift-windows-32, Sources/Windows 32 Kernel/exports.swift — add @_exported public import Windows_32_Kernel_Lock (and, while there, the same omission likely applies to Windows_32_Kernel_Terminal, worth checking in the same pass). Once that lands, this repo's existing Windows Kernel re-export chain (already in place, unchanged by this task) should make Kernel.Lock.Token visible with no further swift-kernel edit needed — no code change is anticipated here beyond what's already pushed at b8d13d3.

The Clock fix and Descriptor-init fix in b8d13d3 remain verified (Windows leg reached and passed both sites with zero diagnostics on either, per the prior comment on this issue). Not closing this issue.

[coenttb]

Windows leg: class fix applied, new unrelated blocker exposed

Full-tier dispatch: run 30687493097 (workflow_dispatch on main, head
b8d13d339ef56d7ed34859c096f356470dbee6ef) —
https://github.com/swift-foundations/swift-kernel/actions/runs/30687493097

Fix applied this session (umbrella/export-completeness class, positive control confirmed)

• swift-microsoft/swift-windows-32 at e8e0fc9: verified by direct enumeration that the
  Windows 32 Kernel umbrella target's dependencies: and Sources/Windows 32 Kernel/exports.swift
  already list all 14 subtargets (Clock, Console, Core, Directory, Environment, File, IO, Lock,
  Memory Map, Process, Socket, System, Terminal, Thread, Time) — no gap found, no change needed
  (already fixed by a prior commit on main before this session started).
• swift-foundations/swift-windows commit c9cf364: the L3-policy Windows.Kernel.Thread enum
  (Sources/Windows Kernel Thread/Windows.Kernel.Thread.swift) only carried per-member typealiases
  for Error, Handle, ID to the L2-canonical Windows.32.Kernel.Thread, omitting Mutex and
  Condition even though windows-32 declares both
  (Windows 32 Kernel Thread/Windows.Kernel.Thread.Mutex.swift). swift-kernel's
  Tests/Support/Kernel.Thread.Test.Harness.swift and Kernel.Thread.Test.Primitives.swift
  reference Kernel.Thread.Mutex / Kernel.Thread.Condition through the cross-platform Kernel
  umbrella, which resolves via this L3-policy site on Windows. Added the two missing typealiases,
  matching the existing idiom. Positive control: before the fix, Mutex/Condition were absent
  from the enumerated typealias set (confirmed by reading the file) while windows-32 declared them
  — the same visibility-gap class as the four prior fixes in this chain.

Windows leg outcome this run: FAILURE — different, unrelated error class

The Mutex/Kernel.Thread symbol from swift-windows-32/swift-windows is no longer implicated.
The Windows (Swift 6.3, debug) leg now fails during emit-module on a different package
entirely — swift-strings (an external L1/L2 dependency, not one of the three repos in scope
for this task):

D:\a\swift-kernel\swift-kernel\.build\checkouts\swift-strings\Sources\Strings\Array.String.Char+PlatformNativeUTF8.Windows.swift:64:13:
error: initializer 'init(_:)' requires the types 'UInt16' and 'String.UTF8View.Element' (aka 'UInt8') be equivalent
error: cannot convert return expression of type 'Array<UInt16>' to return type '[UInt8]'

(repeated across several diagnostic contexts at the same line; final error: fatalError terminates
emit-module).

This is a UTF-16/UTF-8 type-mismatch bug inside swift-strings's own Windows-native UTF8 codec —
not a missing-member/export-completeness gap in windows-32, swift-windows, or swift-kernel's
umbrellas. It is a different class per this task's decision boundary, and swift-strings is
outside the three repos I was authorized to touch (swift-windows-32, swift-windows, swift-kernel).
Recording verbatim and stopping here rather than fixing it in this session.

Other legs, this run

• macOS (Swift 6.3, debug): success
• Ubuntu (Swift 6.3, release): success
• Ubuntu (Swift main nightly, release): failure — tracked advisory class (nightly-toolchain
  drift), not attributable to this change.
• Ubuntu (Swift 6.4.x nightly, release): failure — tracked advisory class (nightly-toolchain
  drift), not attributable to this change.
• iOS/tvOS/watchOS/visionOS Simulator (Swift 6.3, debug): success
• swift-format lint, swift-linter, SwiftLint: success
• DocC archive: success
• Advisory/informational jobs (License header, Test Support Spine audit, Broken symlink scan,
  yamllint, PR title format, API breakage): success or skipped as expected for a non-PR dispatch
• Overall ci-ok: failure (gated on the Windows leg above)

Net

Windows leg is not yet green. The umbrella/export-completeness class this task targeted is now
fully resolved across the two Windows-side repos touched this session (windows-32 already
complete; swift-windows patched at c9cf364). The remaining Windows blocker is a swift-strings
UTF-16/UTF-8 codec bug, outside this task's repo scope — flagging for separate follow-up rather
than expanding scope.