Open alexcrichton opened 2 years ago
In addition to this, we shouldn't be encoding primitive types in the type section (e.g. from above: [[type 0] Interface(Primitive(Unit))]
) at all unless they're explicitly being exported.
oh I believe that was implemented in https://github.com/bytecodealliance/wasm-tools/pull/607 (landed after I initially opened this)
Currently this input dumps as:
0x0 | 00 61 73 6d | version 65546 (Component)
| 0a 00 01 00
0x8 | 01 04 | type section
0xa | 01 | 1 count
0xb | 4c 00 7f | [type 0] Function(ComponentFuncType { params: [], result: Primitive(Unit) })
0xe | 02 03 | import section
0x10 | 01 | 1 count
0x11 | 00 00 | [func 0] ComponentImport { name: "", ty: 0 }
0x13 | 01 04 | type section
0x15 | 01 | 1 count
0x16 | 4c 00 7f | [type 1] Function(ComponentFuncType { params: [], result: Primitive(Unit) })
0x19 | 02 03 | import section
0x1b | 01 | 1 count
0x1c | 00 01 | [func 1] ComponentImport { name: "", ty: 1 }
which is still wrong though with two type sections
Ah right, sorry. I was looking through wasm-tools
's in-flight issues as I was going through the wast
crate for the component model spec update and was just looking at the issue text rather than the output of the tool (which is currently "on the floor" of my branch as it's in progress).
Currently a module textually represented like so:
dumps as:
Here two function types are added (type 1 and type 3 above) but instead only one should be added. There are annotated FIXME annotations for this in the codebase where hashing support needs to be added.