Merge pull request #145 from WebAssembly/loosen-export-rules

Loosen type-export validation rules

Author: lukewagner

design/mvp/Binary.md

@@ -260,8 +260,6 @@ Notes:
 * Validation rejects `resourcetype` type definitions inside `componenttype` and
   `instancettype`. Thus, handle types inside a `componenttype` can only refer
   to resource types that are imported or exported.
-* Validation requires that all resource types transitively used in the type of an
-  export are introduced by a preceding `exportdecl`.
 * The uniqueness validation rules for `externname` described below are also
   applied at the instance- and component-type level.
 * Validation of `externdesc` requires the various `typeidx` type constructors
@@ -335,7 +333,7 @@ Notes:
 * All exports (of all `sort`s) introduce a new index that aliases the exported
   definition and can be used by all subsequent definitions just like an alias.
 * Validation requires that all resource types transitively used in the type of an
-  export are introduced by a preceding `exportdecl`.
+  export are introduced by a preceding `importdecl` or `exportdecl`.
 * The "parses as a URL" condition is defined by executing the [basic URL
   parser] with `char(b)*` as *input*, no optional parameters and non-fatal
   validation errors (which coincides with definition of `URL` in JS and `rust-url`).

design/mvp/Explainer.md

@@ -692,6 +692,10 @@ declarators to be used by subsequent declarators in the type:
 )
 ```
 
+The `type` declarator is restricted by validation to disallow `resource` type
+definitions. Thus, the only resource types possible in an `instancetype` or
+`componenttype` are introduced by `importdecl` or `exportdecl`.
+
 With what's defined so far, we can define component types using a mix of type
 definitions:
 ```wasm
@@ -991,28 +995,6 @@ replaced by `$R` when validating the instantiations of `$c1` and `$c2`. These
 type-checking rules for instantiating type imports mirror the *elimination*
 rule of [universal types]  (∀T).
 
-As a final constraint on both the `export` declarators of a `componenttype` and
-the `export` definitions of a `component`, all transitive uses of abstract
-types in the types of exported functions or values must refer to *exported*
-abstract types (concretely, via the type index introduced by the `export`).
-This ensures that the client of a component is *always* able to define, in the
-client's own type index space, a type compatible with the component's exports.
-For example, in the following component:
-```wasm
-(component
-  (type $R (resource (rep i32)))
-  (export $R' "R" (type (sub $R)))
-  (func $f1 (result (own $R)) (canon lift ...))
-  (func $f2 (result (own $R') (canon lift ...))
-  ;; (export "f" (func $f1)) -- invalid
-  (export "f" (func $f2))
-)
-```
-the commented-out `export` is invalid because its type transitively refers to
-`$R`, which is not a type-export. This requirement is meant to address the
-standard [avoidance problem] that appears in module systems with abstract
-types.
-
 In summary: all type constructors are *structural* with the exception of
 `resource`, which is *abstract* and *generative*. Type imports and exports that
 have a subtype bound also introduce abstract types and follow the standard
@@ -1320,6 +1302,29 @@ In the case of exports, the `<id>?` right after the `export` is bound (the
 `<id>` inside the `<sortidx>` is a reference to the preceding definition being
 exported).
 
+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`). For example, in the following component:
+```wasm
+(component
+  (import "R1" (type $R1 (sub resource)))
+  (type $R2 (resource (rep i32)))
+  (export $R2' "R2" (type $R2))
+  (func $f1 (result (own $R1)) (canon lift ...))
+  (func $f2 (result (own $R2)) (canon lift ...))
+  (func $f2' (result (own $R2')) (canon lift ...))
+  (export "f1" (func $f1))
+  ;; (export "f2" (func $f2)) -- invalid
+  (export "f2" (func $f2'))
+)
+```
+the commented-out `export` is invalid because its type transitively refers to
+`$R2`, which is a private type definition. This requirement is meant to address
+the standard [avoidance problem] that appears in module systems with abstract
+types. In particular, it ensures that a client of a component is able to
+externally define a type compatible with the exports of the component.
+
 Components split the single externally-visible name of imports and exports into
 two sub-fields: a kebab-case `name` (as defined [above](#instance-definitions))
 and a `URL` (defined by the [URL Standard], noting that, in this URL Standard,