BigInt doesn't play nicely with WebGL bindings #800
Comments
|
Thanks for the report! I think it probably makes sense to basically never generate cc @fitzgen |
alexcrichton
added
frontend:webidl
|
I could see it going either way. Right now, it looks like |
This commit tweaks WebIDL expansion of the "long long" and "unsigned long long" types to expand to a union of an 32-bit integer and a double. This reflects how almost none of the APIs on the web today actually work with a `BigInt` (what the previous Rust type of `i64` translates to) and how JS itself fundamentally operates with these APIs. Eventually this may not be necessary if we can natively connect to C++ engines with the `i64` type, but until that day comes this should provide more useful interfaces as they shoudl work in all browsers. Closes rustwasm#800
|
Ok I've opened up #804 with a change to use i32/f64 instead of i64 |
This commit tweaks WebIDL expansion of the "long long" and "unsigned long long" types to expand to a union of an 32-bit integer and a double. This reflects how almost none of the APIs on the web today actually work with a `BigInt` (what the previous Rust type of `i64` translates to) and how JS itself fundamentally operates with these APIs. Eventually this may not be necessary if we can natively connect to C++ engines with the `i64` type, but until that day comes this should provide more useful interfaces as they shoudl work in all browsers. Closes rustwasm#800
This commit tweaks WebIDL expansion of the "long long" and "unsigned long long" types to expand to a union of an 32-bit integer and a double. This reflects how almost none of the APIs on the web today actually work with a `BigInt` (what the previous Rust type of `i64` translates to) and how JS itself fundamentally operates with these APIs. Eventually this may not be necessary if we can natively connect to C++ engines with the `i64` type, but until that day comes this should provide more useful interfaces as they shoudl work in all browsers. Closes rustwasm#800
This fixes an issue with ```swift func vertexAttribPointer( index: GLuint, size: GLint, type: GLenum, normalized: GLboolean, stride: GLsizei, offset: GLintptr ) ``` passing `offset` value of `BigInt` type to the JS function due to `public typealias GLintptr = Int64`, which led to `can't cast BigInt to number` runtime errors. Either WebGL spec is wrong, or browsers implement it incorrectly. Rust folks had a similar issue and they went with `i32`, see rustwasm/wasm-bindgen#800.
I've been experimenting with the
WebGLRenderingContextbindings, and I've discovered that there's a weird interaction between the WebIDL types,wasm-bindgen's type mapping, and what browsers actually support in their WebGL implementations. Basically, there are several methods which take aGLintptr, which is along long, whichwasm-bindgenmaps toi64andBigInt. But the actual API throws an exception if you pass it aBigNum. Using ani32oru32seems to work fine.The simple solution would seem to be changing the definition of
GLintptrin the WebIDL, but is there another alternative that isn't so hacky?The text was updated successfully, but these errors were encountered: