After moving o the newest release(s), I get everything to work with my test suite, except a type using
(list (tuple string (union bool u16)))
, which returns an error of type not valid to be used as export (at offset 0x158
when using Component::new...
This export is all handled with a similar foundation to the make_echo_component code used in the wasmtime codebase. Which change from 8 -> 10 would change this behavior? It essentially does like the combo of list w/ union or tuple with union either.
cc @Pat Hickey.
For example, (list (tuple string string))
works no problem (we emulate this kinda type as a "map" variant)
So, probably related to for to validations and the test suite on this?
Though maybe my answer lies here: https://github.com/bytecodealliance/wasm-tools/blob/main/tests/local/component-model/type-export-restrictions.wast#L69, as they are incompatible, but wasn't being caught in 8.* versions?
Pretty sure it's this: https://github.com/bytecodealliance/wasm-tools/pull/966/commits/6fc54cd57487db05a3e85af969b6b040c9c4df0e
Yes wasms which were previously accepted are not longer accepted after the change the Lann mentioned, and IIRC the make_echo_component
has had updates which you may wish to mirror if you based code on that.
Alex Crichton said:
Yes wasms which were previously accepted are not longer accepted after the change the Lann mentioned, and IIRC the
make_echo_component
has had updates which you may wish to mirror if you based code on that.
yep. Brought in these updates too. And, yes, thank you @Alex Crichton and @Lann Martin, this PR is what def makes sense toward the changes.
Zeeshan Lakhani has marked this topic as resolved.
@Alex Crichton @Lann Martin (or anyone), is there a good link or definitive source or two to find the reasoning(s) on why certain type-export restrictions were made? I'm particularly interested in lists of variants for example, but open to learning more. Thanks!
The component-model repo is as definitive as anything, though I don't know if it contains the answer to your question.
The main motivation for requiring names of exports was to facilitate bindings generation within guest/host languages where few languages have anonymous record or variant types, e.g. Rust requires named structs and named enum
types. The requiring of names is also required for resources so this change was also made in anticipation of resources in the future.
Is this change causing issues for you though? It is theoretically the case that if you're using WIT with up-to-date tooling it's basically a non-issue, so the main pain in theory should be updating everything as opposed to hitting active issues when the tooling is all updated
@Alex Crichton Oh things are generally working and we're updated to the newest version and tooling :). But, we're building this interpreter between WIT and https://ipld.io/ (the underlying data model for IPFS and similar things), and semantically, while IPLD is a recursive data model/structure and can't be modeled directly as is of course, it'd be nice to model some types as lists of a variant type or union type for example or express maps as records and/or lists of tuples, where then you want to expose unions or variants as types for "values" of a tuple (k,v) pair. Nonetheless, thanks for responses to even bring it up :)
Ah ok makes sense, and while tuple<...>
does exist in WIT it sounds like you probably want a sort of map<K, V>
which I think there's an issue for on the component model repo, but otherwise thanks for explaining :+1:
Last updated: Nov 22 2024 at 16:03 UTC