What is "named type restriction" and how to mitigate it?

[markusscherer]

Hi everyone!

I'm currently experimenting with the Component Model and encountered some behavior I do not understand and haven't found documentation for.

Basically, I want to export a variant type from a component definition and wasm-tools validate tells me error: type not valid to be used as export (at offset 0x1a). By checking wasm-tools' code and test cases, I got the understanding that one cannot export a composite type where the constituent types are not named.

One such failing test case from the wasm-tools-repo is:

(component
  (type $t (record (field "f" u32)))
  (type $f (variant (case "c" $t)))
  (export "f" (type $f))
)

My understanding is that $t has to be "named" somehow, but I have not found out how. I already tried to name $t by exporting it ( (export "t" (type $t))), but that did not work.

How can this example be turned into one that validates? Where are these rules discussed? (I did not find anything in the Explainer, but maybe I was looking for the wrong stuff/ did not connect the dots.)

Cheers,
Markus

[alexcrichton]

This restriction may not be super well documented in the spec (I haven't checked in awhile), but basically what you need to do is:

(export $t' "t" (type $t))

and then use $t' in the case.

Exporting a type introduces a new type index, and that new type index is the named one which must be used.

[markusscherer]

Thanks a lot for the prompt response, it worked as you described it!

Actually, I went back to the Explainer and found that:

Validation of export requires that all transitive uses of resource types in
the types of exported functions or values refer to resources that were either
imported or exported (concretely, via the type index introduced by an import
or export). The optional <externdesc>? in export can be used to
explicitly ascribe a type to an export which is validated to be a supertype of
the definition's type, thereby allowing a private (non-exported) type
definition to be replaced with a public (exported) type definition.

So it was indeed a matter of me not looking at the right place. For completeness' sake, in case somebody finds this when looking for a similar validation error: there is a similar validation rule in place for imported types.