BigInt doesn't play nicely with WebGL bindings

[blm768]

I've been experimenting with the WebGLRenderingContext bindings, 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 a GLintptr, which is a long long, which wasm-bindgen maps to i64 and BigInt. But the actual API throws an exception if you pass it a BigNum. Using an i32 or u32 seems to work fine.

The simple solution would seem to be changing the definition of GLintptr in the WebIDL, but is there another alternative that isn't so hacky?

[alexcrichton]

Thanks for the report! I think it probably makes sense to basically never generate BigInt and/or i64 for webidl bindings as they're likely not already accepting it (as you've seen). Instead I think we could perhaps do something like (f64 or i32) to get larger ranges with f64 and more ergonomic ranges with i32?

cc @fitzgen

[blm768]

I could see it going either way. Right now, it looks like BigInt support is extremely limited outside of Chrome, so it's probably not seeing significant use, but I could imagine cases where people would want it in the future. Unless long long shows up in other bindings, this feels like it's more of just an awkward quirk of the WebGL spec being almost a direct port of the OpenGL C API.

[alexcrichton]

Ok I've opened up #804 with a change to use i32/f64 instead of i64