Change NAMESPACE representation in ResolvedBinding Record
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox162 | --- | fixed |
People
(Reporter: dminor, Assigned: allstars.chh)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 6 external files)
|
756 bytes,
application/x-compressed-tar
|
Details |
We currently use star_namespace_star to represent ~NAMESPACE~ in the ResolvedBinding record. This works fine for JavaScript, but any utf-8 string can be used for wasm exports, meaning that *namespace* is a valid wasm export name. If someone attempted to use this name, it would be shadowed by our existing use.
I've attached some claude generated test files illustrating the problem.
Updated•1 month ago
|
Comment 1•1 month ago
|
||
Yoshi, could you take a look when you get a minute?
| Assignee | ||
Comment 2•1 month ago
|
||
ResolvedBindingObject::bindingName() still uses atom,
For WebAssembly module, the [[BindingName]] is the exportName,
https://webassembly.github.io/esm-integration/js-api/index.html#resolve-export
whereas in ECMAScript, the [[BindingName]] is the ExportEntry.[[LocalName]]
https://tc39.es/ecma262/#sec-resolveexport
// module.mjs
var x = 1;
export { x as "*namespace*" };
In ECMAScript, the ResolvedBinding record's [[BindingName]] is "x"
In the ns.wat example from comment 0,
(export "*namespace*" (func $f))
The ResolvedBinding record's [[BindingName]] is "namespace"
I'll fix the [[BindingName]], maybe along with others.
| Assignee | ||
Comment 3•16 days ago
|
||
ResolveExport can return String, NAMESPACE or DEFERRED-NAMESPACE in
[[BindingName]], this patch adds a BindingNameType in ResolvedBindingObject to
indicate the type of the [[BindingName]].
| Assignee | ||
Comment 4•16 days ago
|
||
Add a resolveExport function to ShellModuleObjectWrapper, the function returns
a ResolvedBindingObject, which can be used to verify the type and the value of
[[BindingName]] of Resolved Binding Record returned from ResolveExport.
| Assignee | ||
Comment 5•16 days ago
|
||
Synthetic Module Records can have arbitrary [[ExportNames]].
See https://tc39.es/ecma262/#table-synthetic-module-record-fields
Add a createSyntheticModule test function in the JS shell to simulate export
arbitrary names from a synthetic module or a wasm modules.
| Assignee | ||
Comment 6•16 days ago
|
||
An export named namespace or deferred-namespace shadowed the
internal slots. Name them with a lone surrogate, which no export name
can contain.
Updated•9 days ago
|
| Assignee | ||
Comment 7•9 days ago
|
||
The namespace objects of a module are now stored in reserved slots of its
environment, so the namespace and deferred-namespace bindings that the
parser declared in every module scope are no longer used.
| Assignee | ||
Comment 8•9 days ago
|
||
The spec doesn't handle the case when the [[BindingName]] is namespace,
See https://github.com/WebAssembly/esm-integration/issues/127.
Throws an exception first to prvent hitting assertion.
Comment 11•4 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/82b7ddac5905
https://hg.mozilla.org/mozilla-central/rev/ce62ff0c1127
https://hg.mozilla.org/mozilla-central/rev/4da0efb782eb
https://hg.mozilla.org/mozilla-central/rev/700a75da3c43
https://hg.mozilla.org/mozilla-central/rev/8bf9fe6fca95
https://hg.mozilla.org/mozilla-central/rev/d603d8d72586
Description
•