You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TypeError: Cannot convert a BigInt value to a number
at wasm://wasm/000d1786:wasm-function[165]:0x66f9
at wasm://wasm/000d1786:wasm-function[85]:0x44b2
at wasm://wasm/000d1786:wasm-function[55]:0x381d
at wasm://wasm/000d1786:wasm-function[41]:0x2810
at wasm://wasm/000d1786:wasm-function[180]:0x6ad0
at D:\emscripten\out\test\test_i64_val.js:629:12
at callMain (D:\emscripten\out\test\test_i64_val.js:5377:15)
at doRun (D:\emscripten\out\test\test_i64_val.js:5430:24)
at run (D:\emscripten\out\test\test_i64_val.js:5443:5)
at removeRunDependency (D:\emscripten\out\test\test_i64_val.js:584:7)
at receiveInstance (D:\emscripten\out\test\test_i64_val.js:734:5)
at receiveInstantiationResult (D:\emscripten\out\test\test_i64_val.js:752:12)
at createWasm (D:\emscripten\out\test\test_i64_val.js:778:17)
Thrown at:
at $func165 (wasm://wasm/000d1786:1:26362)
at $func85 (wasm://wasm/000d1786:1:17587)
at $func55 (wasm://wasm/000d1786:1:14366)
at $func41 (wasm://wasm/000d1786:1:10257)
at $main (wasm://wasm/000d1786:1:27345)
at D:\emscripten\out\test\test_i64_val.js:629:12
at callMain (D:\emscripten\out\test\test_i64_val.js:5377:15)
at doRun (D:\emscripten\out\test\test_i64_val.js:5430:24)
at run (D:\emscripten\out\test\test_i64_val.js:5443:5)
at removeRunDependency (D:\emscripten\out\test\test_i64_val.js:584:7)
This is due to generic wiretype being a double. I imagine the easiest fix would be changing so that the return value is stored on the stack instead of being actually returned from the function, so that you can store bigints via HEAP64 and all other numbers via HEAPF64 in the same ABI. cc @brendandahl
Yeah but the alternative is having separate ABIs for "all types" and "int64" like emval_as.
I actually have a refactoring branch that makes this all a lot simpler and fixes bugs like this one as a "side effect".
Problem is, it increases the generated code size a bit - which is why I never landed that - but maybe I should... Code size golfing is fun but the simplicity might be worth it.
Activity
[-]val.call<int64_t>() can't handle bigints[/-][+]val.call<T>() can't handle 64-bit return type[/+][-]val.call<T>() can't handle 64-bit return type[/-][+]val.call<T>() can't return 64-bit integers[/+]sbc100 commentedon Jun 11, 2025
Seems a shame to have to go via linear memory when we have wasm bigint integration enabled by default these days.
RReverser commentedon Jun 11, 2025
Yeah but the alternative is having separate ABIs for "all types" and "int64" like
emval_as.I actually have a refactoring branch that makes this all a lot simpler and fixes bugs like this one as a "side effect".
Problem is, it increases the generated code size a bit - which is why I never landed that - but maybe I should... Code size golfing is fun but the simplicity might be worth it.
[embind] Use a single invoker mechanism
[embind] Use a single invoker mechanism
[embind] Use a single invoker mechanism
[embind] Use a single invoker mechanism
[embind] Use a single invoker mechanism
[embind] Use a single invoker mechanism (#24577)