[web-sys] Incorrect codegen for unsigned long long in IDBVersionChangeEvent

[richard-uk1]

The webidl signature is

[Constructor(DOMString type, optional IDBVersionChangeEventInit eventInitDict),
 Exposed=(Window,Worker,System)]
interface IDBVersionChangeEvent : Event {
    readonly    attribute unsigned long long  oldVersion;
    readonly    attribute unsigned long long? newVersion;
};

but the code in web-sys is

impl IdbVersionChangeEvent {
    pub fn old_version(&self) -> f64;
    pub fn new_version(&self) -> Option<f64>;
}

The f64 should be u64.

[richard-uk1]

I don't know how this works in practice, since u64 isn't supported in ECMAScript. Maybe f64 is the correct type. But then why define something in webidl that can't be represented in js?

[chinedufn]

Yup -> #1088 (comment)

And because WebIDL was never meant to be coupled to JS AFAICT.

[Pauan]

And because WebIDL was never meant to be coupled to JS AFAICT.

To expand on this: WebIDL was intended to be language-agnostic (so it could be used in other languages, like Java).

But in practice it is used almost exclusively with JS, so more recent WebIDL contains more JSisms.

The f64 is correct, since JS doesn't have u64 support.

[richard-uk1]

Closing as invalid.

I'm going to convert like the following

fn to_u64(x: f64) -> u64 {
    if x < 0.0 || x > (u64::max_value() as f64) {
        panic!("out of bounds")
    }
    // cast rounds towards 0
    (x + 0.5) as u64
}

EDIT This doesn't work. Instead I'm only going to support up to 2^(mantissa bits + 1)

(See SO)

[Pauan]

@derekdreery As you found, the biggest integer in JS is Number.MAX_SAFE_INTEGER, which is 9007199254740991

It seems to me that a function like that would be a nice addition to wasm-bindgen, since converting from f64 to u64 is rather tricky.