You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit decouples the string encodings listed for imports/exports
from their core wasm names to instead being registered with WIT-level
constructs instead. Previously the parsing phase of a module would
register a string encoding for core wasm import/export names but this
subverted the logic of validation where detection of how exactly an
import lines up with WIT-level items is determined. The goal of this
commit is to decouple this relation.
Worlds are encoding into custom sections with a known string encoding
for all imports/exports of that world. This can possibly differ for
different parts of an application to theoretically enable one interface
to be imported with UTF-8 and another with UTF-16. This means that
encodings are tracked per-import/export rather than per-world.
Previously this process would assume that there is a single name for an
import's/export's encoding but with new detection and names coming down
the line this is no longer going to be the case. For example with the
new names in WebAssembly/component-model#378 there are new names to be
supported meaning that there's not one single name to register encodings
with.
To help bridge this gap the abstraction here is changed to where
metadata for a module records string encodings on a WIT level, for
example per WIT import/export, instead of per core wasm import/export.
Then during encoding of a component the WIT level constructs are matched
up instead of the core names to determine the string encoding in the
lift/lower operation.
The end goal is that the connection between core wasm names and WIT
names continues to be decoupled where validation is the only location
concerned about this.
0 commit comments