Add support for BigInts and BigInt-based TypedArrays

[j-f1]

Fixes #56. Depends on #183

In the JavaScriptKit package, this PR:

• adds a JSBigInt class that makes it easy to convert between BigInt and Int64/UInt64 values.
  • the Wasm-JS API assumes all i64 values are signed, so I have to hack around that behavior for UInt64 values
  • It would be nice to support standard operations (+-*/ etc) on JSBigInt instances; however, we currently don’t have a way to invoke arbitrary operators in JS from Swift, and there are no function-based equivalents of the operators that we could access instead.
• Automatically casts BigInt values to the requested integer type when using .fromJSValue() (this may cause a crash if the BigInt is outside of the bounds of the requested type, I think)
• Removes support for converting Int64 and UInt64 to JSValue

In addition, a new package (tentatively named JavaScriptKit_I64) includes:

• Support for JSTypedArray<Int64> and JSTypedArray<UInt64>
• Support for converting Int64 and UInt64 to a BigInt JSValue
  • they can still be constructed from a regular number; should I add a way to convert them to a Double value?
• Support for constructing any integer type from a BigInt JSValue
• Support for getting the int64Value and uInt64Value of a JSBigInt
  • …should this API be replaced with Int64(bigInt)/UInt64(bigInt)?
• Support for constructing a JSBigInt from an Int64 or UInt64

also, it:

• changes the integer/float conformances to ConstructibleFromJSValue to reduce boilerplate code (using a Swift 5.5 feature)
• fixes JSSymbol’s JSValue conversion APIs (oops!)
• changes the type for the internal setTimeout function to be a Double (since at least Node.js doesn’t support BigInt timeouts)
• removes JSValueKind.invalid since it is unused
• Uses an assertNever helper function in TypeScript to ensure switches are exhaustive

[github-actions]

Time Change: +279.25ms (3%)

Total Time: 8,247.5ms

Test name	Duration	Change
Object heap/Increment and decrement RC	2,714.75ms	+226.25ms (8%)	🔍

ℹ️ View Unchanged

Test name	Duration	Change
Serialization/Write JavaScript number directly	170.25ms	+0.75ms
Serialization/Write JavaScript string directly	175.5ms	+2.25ms (1%)
Serialization/Swift Int to JavaScript	2,541ms	+19.5ms (0%)
Serialization/Swift String to JavaScript	2,646ms	+30.5ms (1%)

_{performance-action}

[MaxDesiatov]

This needs conflicts to be resolved after JSSymbol merge. That would reduce the diff as well, making it easier to review. Thanks!

[kateinoigakukun]

Can we have a separate module for BigInt support instead of having a new feature flag JAVASCRIPTKIT_WITHOUT_BIGINTS?
I think it would be more straightforward than using ifdefs. Unlike JAVASCRIPTKIT_WITHOUT_WEAKREFS, BigInt is relatively independent of the whole runtime mechanism.

BTW symbol support should be also enabled by an explicit option? We need to define the minimum supported ECMAScript edition, and guard for new features introduced after the edition.

[github-actions]

Time Change: -39ms (0%)

Total Time: 19,157ms

Test name	Duration	Change
Serialization/Write JavaScript number directly	454ms	+36ms (7%)	🔍
Serialization/Write JavaScript string directly	471ms	-28ms (5%)	✅

View Unchanged

Test name	Duration	Change
Serialization/Swift Int to JavaScript	6,142ms	+26ms (0%)
Serialization/Swift String to JavaScript	6,437ms	+144ms (2%)
Object heap/Increment and decrement RC	5,652ms	-216ms (3%)

[j-f1]

I would especially appreciate feedback on the new package name (JavaScriptKit_I64)

[kateinoigakukun]

Module name candidates:

• JavaScriptKitBigIntIntegrationSupport
• JavaScriptBigIntIntegrationSupport
• JavaScriptKitBigIntSupport
• JavaScriptBigIntSupport

Note: The proposal name was JS-BigInt-integration

[MaxDesiatov]

How's about JavaScriptKitI64Support?

[MaxDesiatov]

Ah, sorry, just saw your link to the proposal. 😅 Then I personally vote for JavaScriptBigIntSupport, this seems the least verbose, but still obvious enough for me.

[j-f1]

For JavaScriptBigIntSupport, my concern is that people won’t think BigInts are supported at all by vanilla JSKit, but maybe that isn’t such a big deal and we should just be clear in the README in which cases you need it.

[MaxDesiatov]

Is this ready for review by any chance?

[j-f1]

Yep!

[kateinoigakukun]

I prefer JavaScriptBigIntSupport with README note. Other things are LGTM

[MaxDesiatov]

LGTM, just a few nits. Great work! 👏

[MaxDesiatov]

I wonder if we have to disable Safari WasmTransformer pass when JavaScriptBigIntSupport target is linked? I'm currently seeing WebAssembly.Module doesn't validate: control flow returns with unexpected type. I32 is not a I64, in function at index 89699 error when playing with swiftwasm/WebAPIKit#18

[MaxDesiatov]

I can also confirm that the issue is not reproducible with 95d0c4c, which is prior to the merge commit for this PR.

[j-f1]

That sounds good! Would we need to do anything on the JS side to correctly handle the previous APIs that now return BigInts?

[MaxDesiatov]

I haven't verified yet if disabling the pass fixes the issue with the latest JSKit main, this is only my current theory that could explain the breakage.