Add the Windows half of the converged Kernel.Lock surface

[coenttb]

What

Adds the Windows Kernel Lock L3-policy target and product: Windows.Kernel.Lock as a distinct empty policy enum with per-member typealiases to the L2-canonical Windows.\32`.Kernel.Lock, plus lock/unlock/Immediate.lockwrappers over theWindows.Kernel.Descriptorpolicy typealias. MirrorsWindows.Kernel.Filein this package andPOSIX.Kernel.Lock` in swift-posix.

Why

Byte-range file locking was the one kernel domain with only a POSIX L3 policy tier. Portable code needing a machine-wide file lock had to name POSIX.Kernel.Lock directly — an unconditional edge from portable code to a host substrate. It compiles on POSIX and drags swift-iso-9945 into the Windows build, where it does not compile (cannot find 'errno' in scope). That is exactly the failure mode observed in swift-foundations/swift-build-coordinator's Windows leg.

The Win32 syscall surface (LockFileEx/UnlockFileEx, error/range/kind vocabulary) already existed at L2 with the same shape as the POSIX side. Only this policy tier and the matching swift-kernel export were missing. With both, Kernel.Lock resolves on every supported platform and consumers reach the substrate only behind swift-kernel's own platform conditions.

Paired with swift-foundations/swift-kernel (converged export), which consumes the product this PR publishes.

Notes for review

• Everything here is #if os(Windows)-guarded, so no non-Windows target changes shape.
• Token (the ~Copyable RAII handle) is deliberately not aliased. It is the sole content of the L2 Windows 32 Kernel Lock target, which does not compile off-Windows on swift-windows-32 main (type 'Clock.Continuous' has no member 'now'). Every other lock member is canonical in Windows 32 Kernel Core, already reachable via Windows Kernel.
• Pre-existing red: this package's non-Windows build is already failing on main for that same swift-windows-32 defect (Windows 32 Kernel umbrella depends on Windows 32 Kernel Lock). Reproduced on main with this branch stashed. This PR neither causes nor fixes it; a fix exists upstream but is not on swift-windows-32 main yet.

[coenttb]

Independent review at head b6365aa145e29bee8b2459437e80e29c5b786af9.

Verdict: blocking — the new target does not compile on Windows

The design is right. The implementation collides with a declaration that already exists in this package, and the Windows leg proves it.

The evidence

The Windows leg on the reviewed head had no conclusion — it was cancelled by the CI regime at about an hour. I re-dispatched it (run 31251521303). It was cancelled again at the same ceiling, but not before the compiler reached this target and failed it. Six hard errors, all the same:

Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:50:30:  error: ambiguous type name 'Lock' in 'Windows.Kernel'
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:69:30:  error: ambiguous type name 'Lock' in 'Windows.Kernel'
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:108:30: error: ambiguous type name 'Lock' in 'Windows.Kernel'
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:123:35: error: ambiguous type name 'Lock' in 'Windows.Kernel'
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:124:34: error: ambiguous type name 'Lock' in 'Windows.Kernel'
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:125:33: error: ambiguous type name 'Lock' in 'Windows.Kernel'
error: emit-module command failed with exit code 1

with the compiler naming both candidates:

Sources/Windows Kernel/Windows.Kernel.Lock.swift:23:26:
  note: found candidate with type 'Windows.Kernel.Lock' (aka 'Windows.`32`.Kernel.Lock')
Sources/Windows Kernel Lock/Windows.Kernel.Lock.swift:45:
  note: found candidate with type 'Windows.Kernel.Lock'

So the cancellation is not an evidence gap any more. The leg is red on substance, and it would be red regardless of the time ceiling.

The cause

Sources/Windows Kernel/Windows.Kernel.Lock.swift already declares, on main:

extension Windows.Kernel {
    public typealias Lock = Windows.`32`.Kernel.Lock
}

This PR adds a second Windows.Kernel.Lock — the empty policy enum — in a new target that itself public imports Windows_Kernel. Both declarations are visible at the same time, in the same namespace, under the same name, so every reference in the new file is ambiguous.

The header comment in the new file cites [PLAT-ARCH-008k] and states the point exactly:

Windows.Kernel.Lock is a distinct empty policy enum, not a whole-namespace typealias to the L2-canonical Windows.\32`.Kernel.Lock`

That is the correct reading of the rule. But the whole-namespace typealias the comment argues against is still present in Windows Kernel and was not removed. The PR adds the intended form beside the form it is meant to replace instead of in place of it.

What the fix has to do

The whole-namespace typealias in Windows Kernel has to go, and the policy tier has to live only in the new target. That is a decision with consequences worth stating rather than patching around:

• Any existing consumer resolving Windows.Kernel.Lock through the Windows Kernel umbrella will stop resolving unless it also depends on Windows Kernel Lock. Please check the in-package and in-org consumers before landing, not after.
• Deleting the typealias narrows what Windows.Kernel.Lock means. Today it forwards the entire L2 namespace; afterwards it exposes exactly the members this PR aliases. See the next point — that set is currently short.

Renaming the new enum or qualifying the references would silence the compiler and leave two competing spellings of the same policy namespace, which is the outcome [PLAT-ARCH-008k] exists to prevent. I would not accept that.

Second finding: the converged surface is asymmetric

Independent of the compile error, and worth fixing in the same pass, because it reproduces the exact failure class this chain exists to eliminate.

POSIX.Kernel.Lock aliases Error, Range, Kind, Acquire, Token, Scope, plus Immediate, lock, unlock. This PR aliases Error, Range, Kind, Acquire, Immediate, lock, unlock — no Token, no Scope.

Once swift-kernel exports these as Kernel.Lock, that difference becomes portable-facing: Kernel.Lock.Token and Kernel.Lock.Scope will resolve on POSIX and fail on Windows. Portable code that reaches for the RAII handle compiles for its author and breaks on the Windows leg — which is precisely the shape of the defect the chain is fixing, relocated behind a converged name.

On the two members specifically:

• Token. The stated reason for omitting it is that the L2 Windows 32 Kernel Lock target does not compile off-Windows on swift-windows-32 main because of Clock.Continuous.now. That is no longer true. 2aec5a2 ("Fix Windows lock deadline clock access") is already an ancestor of swift-windows-32 main — I verified the ancestry directly. Windows.32.Kernel.Lock.Token exists and its file is #if os(Windows)-guarded throughout. Please re-measure and alias it; the blocker cited in both the description and the source comment has been resolved upstream.
• Scope. There is no Scope anywhere in swift-windows-32 — I searched both Windows 32 Kernel Core and Windows 32 Kernel Lock. If Scope is inherently a POSIX record-locking notion with no Win32 counterpart, then it should not be reachable through the converged Kernel.Lock name at all, and the asymmetry belongs upstream in swift-kernel's export rather than here. Worth resolving deliberately rather than by omission.

What is right, and should survive the fix

I want to be clear that the approach is sound, because the fix should not be mistaken for a redesign.

• The three-tier placement is correct: L2 canonical at swift-windows-32, L3 policy here, L3 unifier at swift-kernel. The layering table in the file header is accurate.
• The composition is genuinely conditional, not a widened unconditional edge. The whole body is #if os(Windows); the manifest target carries no cross-platform substrate edge; and the consuming side in swift-kernel conditions both the manifest product and the source import. Off-Windows this target contributes nothing.
• The wrappers correctly compose the L2 typed syscall forms with the Windows.Kernel.Descriptor policy typealias, and the function surface (lock, unlock, Immediate.lock) matches POSIX.Kernel.Lock member for member.
• Range.file exists at L2 with a documented Win32 translation of the POSIX l_len == 0 idiom, so the downstream range: .file call site in swift-build-coordinator will resolve.

Chain note

The description says this package's non-Windows build is red on main because of a swift-windows-32 defect not yet on that repository's main. That is no longer accurate: 2aec5a2 is on swift-windows-32 main. swift-microsoft/swift-windows-32#19 is therefore not a prerequisite for this PR — its remaining delta is Windows directory-stream work unrelated to locking. Please re-measure the non-Windows legs rather than carrying the pre-existing-red claim forward.

Next owner and downstream

Author, in this repository: remove the whole-namespace typealias from Windows Kernel, alias Token, settle Scope, and re-run the Windows leg to a real conclusion.

I am holding review of swift-foundations/swift-kernel#9 and swift-foundations/swift-build-coordinator#2 until this compiles. Neither can be soundly assessed while the product they consume does not build.

[coenttb]

Repair lane: both review blocks cleared (head ba57485e)

1. BLOCKING — ambiguous type name 'Lock' in 'Windows.Kernel' — fixed

Confirmed. Sources/Windows Kernel/Windows.Kernel.Lock.swift on main declared the
whole-namespace public typealias Lock = Windows.\32`.Kernel.Lock, and this PR added the L3-policy enum *beside* it rather than *in place of* it — which is exactly what this PR's own [PLAT-ARCH-008k]` header argues against.

Fix: the umbrella typealias file is deleted. It had no in-repo consumers
(grep -rn 'Kernel\.Lock' --include='*.swift' outside the new target returns only the
file itself and a Package.swift comment). The L3-policy enum in
Sources/Windows Kernel Lock/ is now the sole declaration of Windows.Kernel.Lock.

2. Asymmetric converged surface — Token aliased, Scope deliberately absent

Per the programme ruling:

• Token is now aliased. The stated reason for omitting it — that the L2
  "Windows 32 Kernel Lock" target does not build off-Windows — is stale. The clock
  fix 2aec5a2 is an ancestor of swift-windows-32 main; the Clock.Continuous access
  sits inside the os(Windows) guard. Package.swift now declares the
  Windows 32 Kernel Lock product dependency and the comment claiming otherwise is gone.

• Scope stays absent, by decision, not by omission. It has no Win32 counterpart.
  A converged surface that resolves on one platform and not the other is not converged,
  so Scope must not be exposed through the converged Kernel.Lock on either
  platform while it remains one-sided. This is recorded in the file header.

  Note for the L3-unifier (swift-kernel#9): this means Kernel.Lock.Scope must not
  be re-exported from the POSIX leg either. That surface is outside this PR's repository
  and is not being changed here.

Evidence

Off-machine, terminal, and not a skipped leg:

• Run 31264288112, conclusion success.
• ci / matrix / Windows (Swift 6.3, debug) — job 93119879917, conclusion success
  (not cancelled, not skipped). Terminal in ~11 min, well inside the 60-minute ceiling
  that killed the previous two attempts (31251521303 was cancelled mid-Test).
• The new target genuinely compiled on Windows:

  [2989/3014] Compiling Windows_32_Kernel_Lock Windows.Kernel.Lock.Token.swift
  [3099/3115] Compiling Windows_Kernel_Lock Windows.Kernel.Lock.swift
  [3100/3115] Compiling Windows_Kernel_Lock Exports.swift
  Build complete! (622.96s)
  

• ci / matrix / ci-ok — success. swift-format lint, SwiftLint, swift-linter,
  API breakage all success.
• main was merged into the branch (no rebase, no force-push).

Local corroboration: swift build --target "Windows Kernel Lock" on macOS completes
(validates the manifest and product graph), swift-format lint --recursive --strict
exits 0.

Requesting independent review. I am the author and cannot self-approve.

[coenttb]

Correction — Scope exposure is still asymmetric

This corrects the Scope ruling in the repair-lane comment. I withdraw the claim that symmetric non-exposure is already implemented. It is not.

Checked at current exact state

• swift-posix@ab4b8484 still declares public typealias Scope = ISO_9945.Kernel.Lock.Scope under POSIX.Kernel.Lock.
• swift-kernel#9 at a4001fb8 re-exports the whole POSIX_Kernel_Lock module on its POSIX leg. Therefore Kernel.Lock.Scope remains POSIX-visible while this PR leaves Scope absent on Windows.
• The earlier independent review correctly stopped on that asymmetry; the repair-lane comment did not clear it.

Exact owner and downstream hold

swift-posix#7 now owns the cross-platform-safe ownership decision and implementation for Scope. This correction does not decide whether the final public result retains Scope only on an explicitly POSIX surface or supplies an equivalent cross-platform abstraction. swift-kernel#9 and swift-build-coordinator#2 remain held until that owner issue is implemented with exact-head evidence showing no one-sided portable Kernel.Lock.Scope availability.

Independent Win32 record

swift-windows-32#19 is independent of this lock chain. Its review record identified the clock fix, and the live comparison confirms 2aec5a27fd0c511b7fe52e5398d21f1c0a5dd518 is already an ancestor of swift-windows-32 main. Nothing remaining on #19 is a prerequisite for this Scope correction.

[coenttb]

Independent re-review at exact head ba57485eb0f7100410413a039857a2909bd68641.

Verdict: BLOCKED — source clean, package approval gate not met

I reviewed all three commits and the complete four-file diff. The repair removes the conflicting whole-namespace Windows.Kernel.Lock alias, makes the L3 policy enum the sole declaration, adds the correct Windows 32 Kernel Lock product dependency, and aliases Token. The changed Scope note says the exposure remains one-sided and states what must happen on both platforms; it does not claim that the POSIX exposure problem has been solved. swift-foundations/swift-posix#7 remains the separate owner of that follow-up.

Exact-head source evidence is good: PR run 31264288112 concluded success, and Windows job 93119879917 genuinely compiled both Windows_32_Kernel_Lock and Windows_Kernel_Lock before completing successfully.

The approval gate is nevertheless not satisfied. The later exact-head full-tier run 31265590263 concluded failure. Its Windows job and ci / matrix / ci-ok succeeded, but the DocC job was killed with exit 137 in the central symbol-graph combiner after the package build completed. I found no source diagnostic in that failure; resource exhaustion is the inference. The sanctioned public-package approval transaction requires both exact-head ci / matrix / ci-ok and a successful exact-head full tier, so approval must remain withheld.

Smallest next step: the repository maintainer or CI operator should dispatch one fresh full-tier run at this unchanged head. If it succeeds, re-guard this SHA and approve through the bot transaction. If exit 137 repeats, the smallest fixer scope moves to the central DocC workflow owner in swift-institute/.github; no source patch in this PR is presently justified.

Checked evidence: live PR/head/base/state, complete commits and diff, both exact-head runs, Windows logs, and the sanctioned approval contract. Task-attributed evidence: the prior repair and Scope correction records. Inferred evidence: exit 137 reflects runner capacity rather than a product diagnostic. No merge or PR-state change is authorized.

[coenttb]

Owner Issue: #7. This pull request is linked implementation for that record; this comment does not auto-close it.

[coenttb]

Semantic owner link (swift-institute/.github#591): this open PR implements swift-foundations/swift-windows#7. Exact PR head at adjudication: ba57485.