In a type context (Inside an instance or component type), the definition of exportdecl says to bind an $identifier right after the type token (symmetric to func, component, instance, etc; the rule just says bind-id(<externdesc>) and type is one of the <externdesc>) which suggests that the following component should be valid:
(component
(import "i" (instance
(export "foo" (func $foo ...))
(export "inst" (instance $inst ...))
(export "R" (type $R (sub resource))) ;; currently error
))
)Instead the following parses and validates:
(component
(import "i" (instance
(export $R "R" (type (sub resource))) ;; currently ok
))
)It's true that a (non-type-level) export binds an $identifier right after the export, e.g.:
(component
(type $R (resource (rep i32)))
(export $R' "R" (type $R))
)
but this is specific to export definitions which both reference and bind an $identifier (see also CM/#341, which proposes to remove it).
Probably we can't just break the second example, but it'd be useful if the first example started to parse/validate to match the spec.
In a type context (Inside an
instanceorcomponenttype), the definition ofexportdeclsays to bind an$identifierright after thetypetoken (symmetric tofunc,component,instance, etc; the rule just saysbind-id(<externdesc>)andtypeis one of the<externdesc>) which suggests that the following component should be valid:Instead the following parses and validates:
It's true that a (non-type-level)
exportbinds an$identifierright after theexport, e.g.:but this is specific to
exportdefinitions which both reference and bind an$identifier(see also CM/#341, which proposes to remove it).Probably we can't just break the second example, but it'd be useful if the first example started to parse/validate to match the spec.