BigInt support

[MaxDesiatov]

BigInt is supported in Safari 14 on both macOS Catalina/Big Sur and iOS 14, makes perfect sense to support it on our side too, especially to allow proper handling of Int64.

Need to be careful about browser compatibility though. Should JavaScriptKit just fatalError on older browsers when users attempt to use JSBigInt in their code?

Also a good case for a pitch for proper browser versioning in Swift, I'll open a separate toolchain issue for it.

[j-f1]

I was thinking about doing this earlier today, and was trying to figure out how Int64/UInt64 fit into this. Ideally we’d be able to access Big(U)Int64Array from Swift using the existing TypedArray infrastructure but I’m not sure how passing the value across the bridge would work — do we just add two more JSValue types for Int64 and UInt64?

[MaxDesiatov]

Sadly, BigInt64Array isn't supported even in Safari 14. ☹️ Maybe still worth implementing it, just need to be even more careful with runtime checks?

[kateinoigakukun]

BigInt is now supported on Safari, but the latest WebKit doesn't allow to have i64 on the signature of imported function.
For this reason, I had to polyfill wasi functions that have i64 on its interface. https://github.com/kateinoigakukun/swiftwasm-pad/tree/master/Frontend/Sources/i64_polyfill

See also: WebKit test case https://github.com/WebKit/webkit/blob/3a6be938ed0ede574ca96575dbe69f572269c819/JSTests/wasm/function-tests/function-import-return-value.js#L130-L184

[ephemer]

Hi @kateinoigakukun, just wondering what you consider the best practice to work around this issue for Safari < 15?

We are about to bump minimum Safari support to 14.1, so we can use FinalizationRegistry (for autorelease JSClosure), but it'll be a while until we can support v16.

We currently have a build step that runs const { lowerI64Imports } = require("@wasmer/wasm-transformer"); on the built wasm file. Is that still as good as any, or is this something that could reasonably be incorporated into JSKit's new build plugin? Maybe not if it's a workaround that will no longer be needed once enough users upgrade to modern browsers?

[kateinoigakukun]

@ephemer In our production setup, we no longer support browsers without BigInt support, so this hasn’t been a concern for us lately.
That said, using the Wasmer lowerI64Imports transformer is still a reasonable compromise if you need to support Safari < 15.

If you really want to keep supporting those environments, the best way would be to integrate that transformation into JSKit's new build process.

But whether it’s worth doing so depends on your target users. At least for us, we’ve opted not to support those older browsers anymore.

[ephemer]

Hi @kateinoigakukun, thank you for your reply. I notice that @wasmer/transform now panics and fails on binaries built with the latest toolchain. I tried your swiftwasm/WasmTransformer and it seems to work great, but it's not easy to integrate it into our workflow (e.g. CI on various hosts, local dev, etc.).

From what I can see, BigInt support, even with I64 in Safari, appears to be available from Safari 14.1 (although BigIntArray is not available until 15.x). If it does work from 14.1 already then we can just leave the binaries untransformed and put this topic to rest.

If we do need to re-active lowering support though, I will try to try to adapt swiftwasm/WasmTransformer itself work as a wasm build for our development/CI pipelines. I did get it building tonight but I'm not sure how to best pass in and out raw bytes of a wasm library function. We'll cross that bridge when we come to it though..

Thanks again