GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing github.com — Tags · swiftwasm/JavaScriptKit
Tags
0.58.0PackageToJS: Derive WASI and shared memory support from wasm imports (#… …807) * PackageToJS: Derive WASI and shared memory support from wasm imports The SwiftBuild backend's build directory doesn't encode the target triple, so detect the traits derived from it by parsing the imports of the product binary instead. The imports are now parsed as a part of the packaging build graph. * Avoid `import var Foundation.stderr` ``` $ echo "@preconcurrency import var Foundation.stderr" | swiftly run +main-snapshot-2026-08-11 swiftc - -o /dev/null <stdin>:1:28: error: ambiguous name 'stderr' in module 'Foundation' 1 | @preconcurrency import var Foundation.stderr | `- error: ambiguous name 'stderr' in module 'Foundation' 2 | Glibc.stderr:1:32: note: found this candidate 1 | nonisolated(unsafe) public var stderr: UnsafeMutablePointer<FILE>! { get } | `- note: found this candidate /usr/include/stdio.h:151:14: note: found this candidate 149 | extern FILE *stdin; /* Standard input stream. */ 150 | extern FILE *stdout; /* Standard output stream. */ 151 | extern FILE *stderr; /* Standard error output stream. */ | `- note: found this candidate 152 | /* C89/C99 say they're macros. Make them happy. */ 153 | #define stdin stdin ``` swiftlang/swift#89891 * CI: Install Swift toolchain preserving its usr/bin layout Flattening the tarball into /usr/local makes SwiftPM derive a bogus toolchain root, so the swiftbuild build system cannot find swiftc. * PackageToJS: Record every import kind while parsing wasm imports Only memory imports were collected, so `WasmFeatures.isWASI` never saw `wasi_snapshot_preview1` and the generated node.js dropped the WASI import while still constructing a WASI instance. * PackageToJS: run per-target test runners under the swiftbuild build system `swift package js test` assumed the native build system's single combined `<Package>PackageTests` binary: it looked for one `.wasm`/`.xctest` under `.build/<config>/`, packaged it, and ran it. SwiftBuild produces no combined test binary. It emits one `<TestTarget>-test-runner.wasm` per test target under `.build/out/Products/`, plus an aggregate target that only orchestrates building them, so the old lookup failed with "Failed to find 'JavaScriptKitPackageTests.wasm'". (cherry picked from commit c12c7e9) * Install the JS event loop executor in async test targets Because SwiftBuild mode produces a linked executable for each test target. (cherry picked from commit 0a1f926) * BridgeJS: Skip type handle registration for unlinked modules `js test` generates the glue from every test target's skeletons, but the SwiftBuild build system links one binary per test target, so the eager registration hit a missing export. * PackageToJS: Share the linked JS modules with the aggregated glue The per-runner `bridge-js.js` copied to the base output directory for test preludes imports its JavaScript modules relative to itself, so copy the `bridge-js-modules` directory next to it. * BridgeJS: Require the imports object for static-only imported types An imported type looked up from `getImports` contributes its static methods too, but only a constructor marked the imports object as needed, so the glue referenced an undeclared `imports`. * PackageToJS: Generate each test bundle's glue from what its binary links in `js test` generated the glue from every test target's skeletons and handed the same copy to each SwiftBuild per-target runner, which described exports those binaries don't have. Package the aggregated glue once into the shared base directory, where preludes import it by a fixed path, and give each runner glue scoped to the target it links in. This supersedes the registration guard in the JS code generator. 0.57.0BridgeJS: import from external ECMAScript modules, and split snippet … …origins (#795) * BridgeJS: support importing from external ECMAScript modules Extend `from: .module(...)` to accept bare specifiers like `node:path` or an npm package, add `jsName: .default` for default exports, and emit named imports so a wrong export name now fails at module-link time instead of at call time. * BridgeJS: fix named-import regressions found in review Do not require a module export for a wrapper-only `@JSClass`, since a named import is a link-time requirement and nothing looks that name up; accept `jsName: nil` and the explicit `.name(...)` spelling; and validate the tagged `from` form like the plain-string form. * BridgeJS: split snippet and external module import origins Use `from: .snippet("/my-file.js")` for a JavaScript file shipped with the Swift target and `from: .module("node:path")` for an external module, so each keeps its own validation and each mistaken form points at the other. The skeleton encoding is unchanged. * BridgeJS: tag both snippet and module origins in the skeleton Encode `.snippet` as `{"kind":"snippet","path":...}` alongside the existing tagged module form, so the JSON mirrors the Swift cases and a snippet path can no longer encode into a shape that fails to decode. PreviousNext
|
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |