web_sys::Navigator::hardware_concurrency should return u64

[RReverser]

Probably one of those things that can be fixed only on a major version bump: right now Navigator::hardware_concurrency returns f64, but it should be returning u64 as per spec (https://html.spec.whatwg.org/multipage/workers.html#dom-navigator-hardwareconcurrency) and for easier consumption by the end user.

[sparecycles]

I found this via a related nit... the offset parameter for vertexAttribPointer in WebGL is a GLintptr type,

Typedef is long long in the IDL

wasm-bindgen/crates/web-sys/webidls/enabled/WebGLRenderingContext.webidl

Line 25 in 564ce74

typedef long long GLintptr;

and so the generator produces bindings as both i32 and f64, (rather than i32 and u64?)

wasm-bindgen/crates/web-sys/src/features/gen_WebGlRenderingContext.rs

Lines 1942 to 1971 in 564ce74

	# [wasm_bindgen (method , structural , js_class = "WebGLRenderingContext" , js_name = vertexAttribPointer)]
	#[doc = "The `vertexAttribPointer()` method."]
	#[doc = ""]
	#[doc = "[MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/vertexAttribPointer)"]
	#[doc = ""]
	#[doc = "*This API requires the following crate features to be activated: `WebGlRenderingContext`*"]
	pub fn vertex_attrib_pointer_with_i32(
	this: &WebGlRenderingContext,
	indx: u32,
	size: i32,
	type_: u32,
	normalized: bool,
	stride: i32,
	offset: i32,
	);
	# [wasm_bindgen (method , structural , js_class = "WebGLRenderingContext" , js_name = vertexAttribPointer)]
	#[doc = "The `vertexAttribPointer()` method."]
	#[doc = ""]
	#[doc = "[MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/vertexAttribPointer)"]
	#[doc = ""]
	#[doc = "*This API requires the following crate features to be activated: `WebGlRenderingContext`*"]
	pub fn vertex_attrib_pointer_with_f64(
	this: &WebGlRenderingContext,
	indx: u32,
	size: i32,
	type_: u32,
	normalized: bool,
	stride: i32,
	offset: f64,
	);

I guess an f64 can encode more of the integer space of a u64 than an i32 can, but not all of it! Interesting decision by the IDL translator, to be sure.

[Liamolucko]

I guess an f64 can encode more of the integer space of a u64 than an i32 can, but not all of it!

That's sort of an unsolvable problem - even if the type on the Rust side is changed to u64, the number still has to be temporarily converted to an f64 within the JS glue, since a WebIDL long long argument only accepts JS numbers.