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
Refactor how string encodings are specified to wit-component (#401)
* Refactor how string encodings are specified to `wit-component`
This commit is motivated by the recent addition of utf-16 support into
the C generator. Currently that works by "passing a flag" to the
`wit-component` invocation effectively, but the level of abstraction of
this flag isn't quite right:
* The utf16 flag must be specified in two separate locations that need
to be kept in sync.
* Interfaces aren't necessarily all generated in one location, meaning
that it's not always correct to specify utf16 for everything all
at-once. Instead it would be better to on a per-unit-generation
granularity for the encoding to be specified.
The contents of this commit aim to address this issue by changing the
`component-type` custom section in wasm binaries generated by
guest-generators to include the string encoding used. The encoding of
strings wasn't moved into the `Interface` structure since it's an
implementation-level detail rather than an interface-level detail. The
`component-type` custom section is now encoded as a leading version
byte, a string encoding byte, followed by the component as before.
The `wit-component` tooling internally has been refactored to take all
of this into account. Notably the import/exports/default lists were
replaced with a new `BindgenMetadata` structure which handles all the
merging between different custom sections and CLI flags. Additionally
new maps are plumbed around which keep track of core wasm
imports/exports and their registered encoding to ensure that the
liftings/lowerings use the right encoding.
The main limitation of this commit is that the same interface cannot be
imported with two different encodings into the same core wasm module.
Implementing this will require unique names of the import into the
module (e.g. some form of name mangling). Otherwise for now it returns
an error.
It's expected that user-level interactions with `wit-component` are
largely unchanged after this commit. The main change is that if the
`wit-component` tool is run manually then the `--encoding` flag is
largely not necessary unless the binary doesn't previously have
`component-type` embedded sections.
* Fix demo build
0 commit comments