Use alloc::vec::Vec instead of Vec for no_std support

[Dinnerbone]

Whilst no_std seems technically supported, in practice it's unusable with a bunch of web-sys features due to relying on the implicit std::vec::Vec in places. This fixes that by using alloc::vec::Vec explicitly, which works in both std and no_std.

A quick test would be to cargo check -p web-sys --no-default-features --features ImageData - fails before this PR, succeeds after it.

After this change, we don't actually use std anywhere within web-sys - it could be permanently no_std if so desired. That'd certainly help keep it no_std compatible in the future.

[daxpedda]

Exposing an std crate feature in web-sys was a mistake to begin with I believe. Too late now unfortunately. This also prevents us from properly testing it in CI.

In any case, thank you for catching this!
Could you just add a changelog entry?

[Dinnerbone]

Exposing an std crate feature in web-sys was a mistake to begin with I believe. Too late now unfortunately. This also prevents us from properly testing it in CI.

In that case; how about we just switch web-sys to be no_std always, and have the std feature only pass through to wasm-bindgen which does need it? We can do the same for js-sys, which doesn't need std either.

It wouldn't solve testability entirely but it'd mean we at least have two crates where std can't sneak in unnoticed

[daxpedda]

In that case; how about we just switch web-sys to be no_std always, and have the std feature only pass through to wasm-bindgen which does need it? We can do the same for js-sys, which doesn't need std either.

js-sys actually has a single use for std: implementing Error for TryFromIntError. But the issue with testing in CI is that we can't use all-features for web-sys without including std and listing all other web-sys features is a no-go. The same issue doesn't apply to js-sys so that's not the problem.

So making web-sys always no_std is a great idea! Feel free to go ahead and do that, I can do the change to CI in a follow-up.

[Dinnerbone]

js-sys actually has a single use for std: implementing Error for TryFromIntError

That's stable in core now - but I just noticed the MSRV is 1.57 which is too early. Oh well, someone in the future can do that :D

Added changelog and made web_sys no_std unconditional! And have a great Christmas! <3

[daxpedda]

Suggested change

	* `web-sys` crate now fully works on `no_std`.
	* Fixed `no_std` support for all APIs in `web-sys`.

It sounds like the std Vec usage was on purpose, it was just an oversight 😅!

Just for context: this is always a bug, because crate features have to be additive and they are not supposed to break compilation when you add a crate feature!

[daxpedda]

Thank you and merry Christmas as well!

[daxpedda]

Self note: this is already covered by CI, because running cargo build -p web-sys --all-features is now enough to trigger a build-failure if the Std prelude is used anywhere.

[bushrat011899]

This bit me while working on no_std for Bevy (you can read about the efforts here). For future reference, if you do this:

#![no_std]

#[cfg(feature = "std")]
extern crate std;

You can have an std feature without toggling the implicit prelude, which catches these kinds of import issues when compiling with all features.

[daxpedda]

Uh, that's pretty neat!
Thanks, will keep this in mind!