Directly import `JsString` literals from JavaScript

[CryZe]

Motivation

With the JS String Builtins proposal having been stabilized in Chrome and soon stabilizing in Firefox, it would be a great idea to start supporting it from wasm-bindgen. Most importantly I think it would be great to be able to directly import JsString literals directly from the browser without having to run any code to do the UTF-8 to UTF-16 conversion at all.

Proposed Solution

Provide a macro js_sys::string! macro that can be used like so:

string!("Hello, World!")

this expands to an internal wasm-bindgen machinery similar to describe which wasm-bindgen's CLI can then interpret and transform into an imported externref like so:

(global (import "strings" "Hello, World!") (ref extern))

a fallback to constructing the JsString at runtime should be available in case the feature is disabled in wasm-bindgen.

Alternatives

One alternative would be to not make use of the proposal at all and instead simply generate the literals into the __wbindgen_init_externref_table function where other types of literals could even be supported such as BigInt literals. This would also directly put the literals at a constant index of the externref table, whereas the proposal will give us a global which would need to be placed in the table at runtime.

Additional Context

None yet

[CryZe]

And turns out it's already a thing: https://rustwasm.github.io/docs/wasm-bindgen/reference/static-js-objects.html#static-strings

[CryZe]

Reopening, because the functionality as it exists is very impractical to use:

• There is a full on function import for each string. This bloats both the JS and wasm side.
• The way to define each literal requires this fairly large block and a full on named constant.
• It's a lazy thread local, which has a runtime cost every time you access it.
• Every time you access it you need THE_STRING.with(|s| actual_usage(s)), which makes it even more unergonomic.

All of these should go away if the literals are just stored like the other literals in the externref table.