feat: Add Wasm platform by conditionally building without swift-nio - #3
Open
scottmarchant wants to merge 2 commits into
Open
feat: Add Wasm platform by conditionally building without swift-nio#3scottmarchant wants to merge 2 commits into
scottmarchant wants to merge 2 commits into
Conversation
scottmarchant
force-pushed
the
feat/wasi-nio-free
branch
from
July 29, 2026 00:20
224a265 to
84ba06c
Compare
scottmarchant
force-pushed
the
feat/wasi-nio-free
branch
2 times, most recently
from
July 30, 2026 02:49
f008acf to
8774c42
Compare
scottmarchant
changed the title
Collaborator
Author
|
I'm marking this as ready for review temporarily to run CI. Please ignore for a bit. I will either move this back to draft or formally present it for review soon |
scottmarchant
marked this pull request as ready for review
July 30, 2026 03:06
scottmarchant
changed the title
scottmarchant
changed the title
Motivation: The SQL drivers beneath SQLKit cannot build SwiftNIO for `wasm32-unknown-wasip1`: NIOPosix is built on POSIX sockets and threads, neither of which WASI preview 1 provides. SQLKit itself needs very little of SwiftNIO, only `EventLoop` and `EventLoopFuture`, and only for the legacy half of an API whose `async` half is already the recommended one, so it can build without it, given somewhere to put the differences. The goal is one implementation with a few conditional declarations, not a second copy of the package that has to be kept in step by hand. Modifications: Gate the legacy `EventLoopFuture` surface with `#if canImport(NIOCore)`. Keying on `canImport` rather than on a platform keeps the sources in step with whatever the manifest resolves for the target being built, and makes the gate unconditionally true wherever SwiftNIO is present. What drops out where it is absent: the `eventLoop` property, the `execute(sql:_:) -> EventLoopFuture<Void>` requirement and its default bridge to `async`, the `EventLoopFuture` variants of `SQLQueryBuilder.run()` and of the `SQLQueryFetcher` `first`/`all`/`run` families, the NIOCore re-exports, and the deprecated `SQLBenchmarker` future bridges. Each `#if` encloses the doc comment of the declaration it gates rather than sitting between the two. A `#if` in that position detaches the comment: the declaration still compiles, but the symbol graph reports it as undocumented, so the published API docs lose the entry with no build-time diagnostic. Placed correctly, the doc comments are byte-identical to before. Result: Wherever SwiftNIO is available the public API, the documentation and the symbol graph are unchanged. `swift build --target SQLKit -Xswiftc -emit-symbol-graph` emits the same symbols with the same `docComment` line counts as before, and `diagnose-api-breaking-changes` reports no differences. Where it is absent the `async` surface, already the recommended API on every one of those calls, is unaffected and becomes the only one.
Motivation: Since vapor#190 and swift-nio's WASI support, SQLKit itself already builds for `wasm32-unknown-wasip1` with NIOCore linked. The drivers beneath it do not: NIOPosix needs the POSIX sockets and threads WASI preview 1 lacks, so a driver on that platform has no SwiftNIO at all, and a SQLKit that kept its `EventLoopFuture` surface there would impose requirements no driver could implement. Gating NIOCore out keeps `canImport(NIOCore)` uniformly false across the stack on WASI, so one condition selects the async-only configuration everywhere. Modifications: Gate the NIOCore product on `.when(platforms: nonWASIPlatforms)`. Target dependency conditions are evaluated per platform, so on WASI the product is simply not linked and the `canImport(NIOCore)` gates select the `async` API. `.when(platforms:)` can only include, never exclude, so excluding one platform means enumerating the others; the list is the set SPM 6.1 knows about, noted as such so it is not extended without also raising the manifest's tools version. The test target's NIOCore and NIOEmbedded dependencies are gated the same way, as are the suite's imports of them. The suite exercises the `EventLoopFuture` API and is not run on WASI, and `swift build` evaluates `--explicit-target-dependency-import-check` for every target in the graph, including the test target it does not build. Result: On every other platform the resolved dependency set is byte-identical to before. On WASI the build graph contains no SwiftNIO module: not NIOPosix, not NIOCore, not NIOConcurrencyHelpers.
scottmarchant
force-pushed
the
feat/wasi-nio-free
branch
from
July 30, 2026 03:14
8774c42 to
68c28ac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds SQLKit on
wasm32-unknown-wasip1without SwiftNIO. Since vapor#190 and swift-nio's WASI support, SQLKit itself already builds there with NIOCore linked; SwiftNIO is elided anyway because the drivers beneath SQLKit cannot build it at all (NIOPosix needs the POSIX sockets and threads WASI preview 1 lacks), so nothing on that platform can implement anEventLoopFuturesurface, and keepingcanImport(NIOCore)uniformly false across the stack means one condition selects the async-only configuration everywhere. Compiling under Embedded Swift needs a further set of gates, including a change to how the bound-parameter constraint is spelled; that work is kept out of this PR and is not being proposed yet, which keeps this diff small.Changes:
EventLoopFuturesurface goes behind#if canImport(NIOCore):SQLDatabase.eventLoop, the future-returningexecute(sql:_:)requirement and its default bridge,SQLQueryBuilder.run(), the threeSQLQueryFetcherfuture families, the NIOCore re-exports, andSQLBenchmarker's two deprecated bridges. Theasyncsurface, already the recommended API at every one of those call sites, is untouched and is all that remains where SwiftNIO is absent.#ifencloses the doc comment of the declaration it gates rather than sitting between the two. A#ifin that position detaches the comment: the declaration still compiles, but the symbol graph reports it as undocumented and the published docs lose the entry, with no build-time diagnostic.NIOCore(and the test target'sNIOCore/NIOEmbedded) with.when(platforms: nonWASIPlatforms), the same spelled-out-list idiom as Add support for WASILibc apple/swift-nio#2671 and swift-crypto, with a comment pinning the list to the manifest's tools version. The test suite's imports of those modules gate on the same condition, becauseswift buildevaluates--explicit-target-dependency-import-checkfor every target in the graph, including the test target it does not build.Where SwiftNIO is present, nothing changes: every gate is unconditionally true, and
swift package diagnose-api-breaking-changesreports no breaking changes in SQLKit or SQLKitBenchmark.swift build -Xswiftc -emit-symbol-graphemits the same symbols with the samedocCommentline counts as before.What WASI loses: the
EventLoopFuturehalf of the API.SQLDatabase.eventLoop, the future-returningexecute(sql:_:)andSQLQueryBuilder.run(), the future variants of theSQLQueryFetcherfirst/all/runfamilies, the NIOCore re-exports, andSQLBenchmarker's deprecated bridges. Theasyncsurface, already the recommended API, is what remains. One driver-facing nuance: the default implementation of theasyncexecute(sql:_:)forwards to the future-returning requirement, so where SwiftNIO is absent there is no future overload to forward to and drivers implement theasyncrequirement directly, which is the primitive they should be implementing anyway.Verification:
swift buildandswift test: green, 169 tests, including with CI's--explicit-target-dependency-import-check error -Xswiftc -require-explicit-sendable.--swift-sdk swift-6.3.1-RELEASE_wasm): green with the same flags, zero SwiftNIO object files, no NIO symbols in the built objects.SQLKitBenchmarkstill builds for regular WASI.with_wasm: truetovapor/ci.On tests: no test cases are added. The change introduces no behavior on any platform that compiled before (every gate is unconditionally true where SwiftNIO is present, and the symbol graph is byte-identical), and the configuration it does add is exercised by the wasm CI lane.
Notes for review: every gate is a capability gate (
canImport), inSources/only, never in a manifest; there is noos(WASI)anywhere. All three packages in this stack gate the same modules on the same condition, and a package that did build NIOCore for WASI would fail loudly at compile. No SwiftPM traits, no versioned manifest, no tools-version bump, no new dependencies.