Skip to content

Export the platform-matched Kernel.Lock surface #10

Closed
Feature
Closed
Export the platform-matched Kernel.Lock surface#10
Feature
Assignees
coenttb
Labels
enhancementNew feature or request

Description

@coenttb
coenttb
opened on Aug 8, 2026

Problem

swift-kernel does not explicitly export a platform-matched Kernel.Lock surface. POSIX availability currently arrives transitively, while Windows has no corresponding unified export. Pull request #9 implements the owner-side export, but no Issue currently owns the problem, outcome, and evidence.

Proposed outcome

swift-kernel main explicitly exports the platform-matched L3 lock owner on each supported platform, so portable consumers name Kernel.Lock without importing a host substrate. Exact-head platform evidence must show that the unified public surface has no one-sided Scope availability; swift-compositions/swift-posix#7 owns that separate decision.

Alternatives considered

Relying on umbrella re-exports is rejected because it hides whether the dependency exists and leaves the Windows surface absent. A consumer-local alias is rejected because the unifier owns platform selection.

Compatibility and migration impact

This makes an existing accidental POSIX surface explicit and adds its Windows counterpart. No Project admission, priority, repository, visibility, release, or dependency-edge decision is made here.

Activity

  1. coenttb
    added the
    Feature
    issue type on Aug 8, 2026
  2. coenttb
    added a parent issue on Aug 8, 2026
  3. coenttb
    self-assigned this
    on Aug 8, 2026
  4. coenttb
    added
    enhancementNew feature or request
    on Sep 29, 2026

  5. coenttb commented on Oct 6, 2026

    @coenttb
    coenttb
    on Oct 6, 2026
    CollaboratorAuthor

    [fleet supervisor, not Coen]

    Checkpoint 2026-10-06: the export is on main. At 35d185c, Sources/Kernel/Exports.swift re-exports POSIX_Kernel_Lock (Darwin/Glibc/Musl) and Windows_Kernel_Lock (Windows), and Package.swift depends on the POSIX Kernel Lock and Windows Kernel Lock products, each platform-conditioned. It landed in 90b1cce (2026-08-20). The exact-head platform evidence this issue requires is not yet shown: main CI 37128524426 at 35d185c (2026-10-03) failed and its cause is undiagnosed. The Scope question remains with swift-posix#7.

  6. coenttb commented on Oct 7, 2026

    @coenttb
    coenttb
    on Oct 7, 2026
    CollaboratorAuthor

    [fleet supervisor, not Coen]

    New consumer evidence for this issue (2026-10-07): swift-institute/institute run 37675316779, Windows job 112984582652, resolved swift-kernel at main 35d185c. It fails emitting module Kernel_Core:

    Sources/Kernel Core/Kernel.Failure.swift:15:26: error: 'Lock' is not a member type of enum 'Windows_Kernel.Kernel' (aka 'Windows_32_Core.Windows.Kernel')
Sources/Kernel Core/Kernel.Failure.swift:7:17: error: type 'Windows.Kernel.Failure' does not conform to protocol 'Equatable'

    All 8 error lines are in this one file: case lock(Kernel.Lock.Error) has no platform-matched Kernel.Lock on Windows, which is this issue's problem. The earlier pull request #9 (converged-kernel-lock-export) is closed unmerged. This is now being worked under this issue, with the package and consumer Windows build as acceptance.

  7. coenttb
    added a commit that references this issue on Oct 7, 2026

    Export the Windows lock surface from Kernel Core (#28)

    275d2fe

  8. coenttb commented on Oct 7, 2026

    @coenttb
    coenttb
    on Oct 7, 2026
    CollaboratorAuthor

    [fleet lane A, not Coen] Kernel Core Windows Lock edge merged; Windows evidence pending. Not closing.

    • Consumer failure (institute run 37675316779, Windows job 112984582652, swift-kernel 35d185c): Kernel.Failure.swift:15:26: 'Lock' is not a member type of enum 'Windows_Kernel.Kernel'.
    • Cause: Kernel.Failure in Kernel Core names Kernel.Lock.Error.
      • On POSIX that arrives through Kernel Core's exported POSIX_Kernel, which re-exports POSIX_Kernel_Lock.
      • On Windows, Kernel Core never depended on swift-windows' "Windows Kernel Lock".
      • The Kernel target already exported the per-platform Lock targets; only Kernel Core lacked the Windows edge.
    • Fix, PR Export the Windows lock surface from Kernel Core #28 (6096f03): Kernel Core depends on "Windows Kernel Lock" (Windows only) and exports Windows_Kernel_Lock in its Windows branch.
    • Review of the other Kernel.* names in Kernel Core: all have Windows owners Kernel Core already imports, or are gated !os(Windows). Lock was the only gap.
    • Local: a fresh clone builds and passes 348 tests on macOS. The Windows branch is not compiled on macOS.
    • PR checks (Linux ×2, Quality, ci-ok) passed. The PR plan skipped the Windows leg.
    • Squash-merged, bound to the head: main = 275d2fe (same tree as 6096f03).
    • Pending:
      • the package Windows job on main, run 37689056414 (Plan still running);
      • one consumer Windows re-verification resolving 275d2fe or later.

  9. coenttb commented on Oct 7, 2026

    @coenttb
    coenttb
    on Oct 7, 2026
    CollaboratorAuthor

    [fleet lane D, not Coen] Consumer verification for this issue, the fix at 275d2fe: one dispatched CI run of swift-institute/institute on main.

    • Run 37694829186: workflow_dispatch on main at 313ff05f. Windows job (Build · Windows · release): 113050151907, Swift 6.4.0-RELEASE (the +Asserts toolchain).
    • Revisions resolved (job resolution log):
      • swift-compositions/swift-kernel at main (275d2fe), the fix;
      • swift-compositions/swift-windows at main (94a9b7e);
      • swift-microsoft/swift-windows-32 at main (e050c4a);
      • swift-compositions/swift-json at main (350bd7e), the package in the failure path.
    • Conclusion: failure, but no longer a source compile error.
      • 0 errors in swift-kernel. The Kernel.Failure.swift:15 Kernel.Lock.Error error from the previous consumer run (37675316779) is gone. The log has no error: diagnostic in any source file.
      • First failure: error: compile command failed due to exception 29, a crash of the Swift compiler itself.
        • It happens during IR generation for swift-json/Sources/JSON/JSON.Decode.Implementation.swift.
        • It crashes while emitting the SIL function $s4JSONAAV6DecodeO14ImplementationV14lexNumberValue8RFC_8259AHO0E0VyAI5ErrorOYKF (JSON.Decode.Implementation.lexNumberValue(…) throws(RFC_8259….Error)).
        • It aborts at function getMangledName at IRGenDebugInfo.cpp:1112.
        • The same abort appears 9 times, once per compile job that covers that file, and nothing else fails.
      • So the next blocker is swift-compositions/swift-json at 350bd7e: a Windows-only compiler assertion in debug-info mangling for that typed-throws function.
      • The workaround or fix and the owner are for S to route. swift-json's own last Windows run (2026-10-05, at 350bd7e) stopped earlier, at the old swift-windows-32 error, so this looks like the first time the build reaches this file on Windows.
    • For this issue: the swift-kernel part of the consumer build passes. Institute's Windows build is not green yet, because of the compiler crash in swift-json. I am not closing this; S decides on the package and consumer facts. No rerun.

  10. coenttb commented on Oct 7, 2026

    @coenttb
    coenttb
    on Oct 7, 2026
    CollaboratorAuthor

    [fleet supervisor, not Coen]

    Closing as completed, scoped to this package's Windows Kernel.Lock repair.

  11. coenttb
    closed this as completedon Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

Feature

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions