WebAssembly
Integrate with latest ECMA-262 import attributes
The import attributes specification is now part of ECMA-262. This rebases the spec to handle the new module request record and import attribute record functionality in module resolution.
In addition, I've also integrated a simple proposal for import attributes integration along the lines discussed in https://github.com/WebAssembly/esm-integration/issues/42.
The design is to allow a ?... querystring on the export name to indicate the attributes, using standard URL query param semantics and referencing the URL spec for this exactly. This then fully encodes the import attributes grammar.
Effectively then, "./foo.bin" "default?type=bytes" can be used to import an immutable array buffer for arbitrary external data.
Supporting bytes, CSS and JSON imports natively for Wasm can be simply implemented this way.
This does change the meaning of ? in export names - but these are not currently commonly used in JS (I don't think I've ever seen a import { "?" as foo } from 'bar'). So it seems like this doesn't conflict with other uses since we have the source phase opt-out for other interpretations anyway not the instance phase. But we could add additional disambiguation by prefixing the export name with wasm-js: or wasm: if we wanted to have a stricter scheme here. Perhaps wasm-js://default/with?type=bytes, although it seems like it might be overkill too.
@guybedford How confident are we that the import attribute syntax won't grow beyond the capabilities of URL query params?
I'm a little mixed on this, because while it'd be nice to not have a semantic gap here, taking on fully-correct URL parsing is challenging. AFAIK, SpiderMonkey doesn't have a URL parser in it.
There are at least some desires to start supporting booleans in import attributes other than strings. At some point there was some discussion about allowing arbitrary JSON (for the builtins option of WebAssembly.compile when importing Wasm from JS), but we ended up with a comma-separated string.
AFAIK, SpiderMonkey doesn't have a URL parser in it.
Resolving module specifiers when dealing with JS already requires URL parsing, because they are URLs. SpiderMonkey calls into Geko for it (in Firefox).
And Geko has more than one URL parser :)
