Export the converged Kernel.Lock surface on every platform - #9
Conversation
Kernel.Lock resolved only by accident: Kernel Core's platform-conditioned @_exported import of the POSIX_Kernel umbrella happens to carry POSIX_Kernel_Lock, and there is no Windows equivalent. Portable code that needed a machine-wide file lock therefore had to name POSIX.Kernel.Lock directly, which drags swift-iso-9945 into the Windows build where it does not compile. Export the matching L3-policy lock target from the Kernel umbrella under explicit platform conditions instead, so Kernel.Lock — the converged name portable code consumes — resolves through the typealias chain on POSIX and Windows alike, and the substrate is reached only behind those conditions. Requires swift-foundations/swift-windows#6 for the Windows Kernel Lock product.
Guarded hold —
|
coenttb
left a comment
coenttb
left a comment
There was a problem hiding this comment.
Independent review at exact head a4001fb, against current base 2ba5e08. The head is one commit ahead and three commits behind that base; merge base cadc414.
Verdict: BLOCKED. This is a COMMENTED verdict only; no approval or merge is warranted.
Classification
- Source correctness: blocked by an unavailable declared product at the current dependency heads. Package.swift lines 245–250 requires Windows Kernel Lock, but swift-windows main at 41e619315c812bf3c24e358fe675ba7d2e9718a8 does not publish it. Exact-head run 31251538972, stable job 93089736030, failed before compilation with “product 'Windows Kernel Lock' ... not found”. This is an upstream sequencing failure, not evidence against the lock wrappers themselves.
- Architecture: blocked twice. First, the whole POSIX lock module re-export makes the supposedly converged API one-sided. Second, Lock is attached only to the aggregate Kernel target/product instead of receiving the same narrow target/product boundary as the other kernel domains, forcing a lock-only consumer to compile the umbrella.
- Portability: blocked. The new source conditional at Exports.swift lines 143–146 tests module availability for platform identity. Platform selection here must follow the target triple and match the manifest conditions; a missing module must fail the build, not silently remove the public API.
- Exposure: clean for the reviewed two-file diff and this payload. I found no private machine path, credential, private-repository detail, task/session identifier, or prohibited attribution.
- Evidence: insufficient. The exact-head run failed. Its Windows and simulator jobs were skipped, and the PR-tier release jobs select build-only behavior; no test suite executed at this head. The successful format and linter jobs do not establish API symmetry or platform compilation.
Blocking findings
[P1] Exports.swift line 144 re-exports the complete POSIX_Kernel_Lock module. At swift-posix ab4b8484, lines 40–41, that module publicly aliases POSIX.Kernel.Lock.Scope. The repaired Windows policy deliberately has no Scope counterpart. Because Kernel is the POSIX namespace typealias on that leg, importing Kernel therefore exposes Kernel.Lock.Scope on POSIX and not on Windows. The earlier symmetric-non-exposure claim is false. The durable owner is swift-posix issue 7; this PR must not treat it as resolved.
[P1] The exact head cannot resolve its dependency graph until swift-windows PR 6 lands. A platform-conditioned product still has to exist in the dependency manifest; the current failure occurs even on Ubuntu during package validation. This leaves all source and platform evidence for this head absent.
[P2] Package.swift lines 226–253 puts the lock dependencies only on the aggregate Kernel target. Lock has its own semantic surface, platform dependencies, and a demonstrated consumer that wants it without File, Event, Completion, Clock, and the rest. It needs a narrow Kernel Lock target/product, with the umbrella composing that target; the downstream coordinator should consume that product.
[P2] Replace the new canImport platform branch with deterministic os-based target-identity conditions aligned with the manifest. The current spelling can fail open by omitting Kernel.Lock when module resolution changes.
Smallest owners and re-review condition
- swift-posix issue 7 owns the Scope disposition and implementation. It must produce a cross-platform-safe portable result; this review does not choose whether Scope remains POSIX-only behind a non-converged surface or gains a lawful counterpart.
- The swift-windows PR 6 maintainer/CI owner must first get its existing exact head through the required full tier and onto main so the product resolves.
- This PR's author owns the narrow Kernel Lock boundary and deterministic platform condition, plus any unifier adjustment required by the issue 7 disposition.
Re-review only a new exact head after those prerequisites are on main, the branch is updated against the live base, the portable Kernel.Lock surface has no one-sided Scope reachability, and exact-head full-tier evidence shows real Windows and Apple-simulator execution plus executed tests rather than build-only or skipped jobs.
|
Owner Issue: #10. This pull request is linked implementation for that record; this comment does not auto-close it. |
1 participant
What
Sources/Kernel/Exports.swiftgains a platform-conditioned export of the L3-policy lock target —POSIX_Kernel_Lockon Darwin/Glibc/Musl,Windows_Kernel_Lockon Windows — alongside the matching conditioned product dependencies in the manifest.Why
Kernel.Lockpreviously resolved only by accident on POSIX:Kernel Core@_exported-imports thePOSIX_Kernelumbrella, which happens to carryPOSIX_Kernel_Lock. There was no Windows counterpart and no declared edge naming the lock surface anywhere.The consequence is visible downstream. Portable code that needs a machine-wide file lock had to name
POSIX.Kernel.Lockdirectly — 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). swift-foundations/swift-build-coordinator's Windows leg fails exactly that way today.Because
Kernelis alreadytypealias Kernel = POSIX.Kernel/Windows.Kernel, exporting the L3-policy lock target is all that is needed:Kernel.Lockthen resolves through the existing typealias chain on both sides, and the platform substrate is reached only behind the conditions here — the [PLAT-ARCH-008e] three-tier discipline the descriptor and socket chains in this same file already follow.Dependency
Requires swift-foundations/swift-windows#6, which publishes the
Windows Kernel Lockproduct this PR consumes. Merge that first.Consumer: swift-foundations/swift-build-coordinator (TX-APP1G), which switches from
POSIX Kernel Lockto this converged owner.Notes for review
POSIX_Kernelumbrella. An umbrella re-export hides both missing and present dependencies and makes import measurement read a clean zero either way; the converged surface should be named where it is owned.