wip: allow to specify module's interface in wasm-smith

[matklad]

fix #276

[matklad]

@fitzgen this turned out to be a bit more compliaceted than I though, for two related reasons.

First, when we generate arbitrary imports, we want to pick a type from an already existing set. So, I solved this problem by moving the bulk of the logic to the point where we generate arbitrary types, such that, at the point where we generate the import, we can basically re-use the same logic, and just pick a type from a more restricted set

Second, the EntityType enum relies on some kind on instances already being in the module. For example, EntityType::Func contains an index into a table. The problem here is that in Config we don't have access to those tables, as they don't exist yet. Not sure what's the best path here -- should be just duplicate the EntityType hierarchy for config, such that config-flagored version do not rely on indexes?

The PR in the current state implements the minimal amount of work to make just functions work. Opening early to get design feedback.

[fitzgen]

Regarding the first point: I think we generally want to avoid mixing up the code paths for arbitrary imports vs available imports together too much. I think it will make everything much harder to reason about. To be specific, when we are generating imports from an available set, rather than limiting ourselves to things for which we already have a compatible type definition, we can choose an available import, add its type definition if it is not already defined, and then add the import referencing the maybe-just-defined type. Having all this in a separate code path/method from arbitrary imports should make implementation and maintenance easier for both paths.

Regarding the second point:

should be just duplicate the EntityType hierarchy for config, such that config-flagored version do not rely on indexes?

I think the answer is "yes" here. It is annoying to type out, but that only has to happen once, and we don't expect these definitions to change frequently, so the maintenance/syncing overhead is low. This approach will provide the best user experience for folks writing custom Configs with available imports.

[matklad]

This all makes sense to me, @fitzgen! Ptal, is this closer to what you have in mind? Want to get 👍 on the design before I get into modules and instances :-)

One specific question:

• should I remove the import from the set of choices after it is used?
• or should I keep it in (allowing dupes, as per wasm spec), and also keep the cell-based caching of import types (I only create a new type when I use the import for the first type)

[fitzgen]

This is looking great!

should I remove the import from the set of choices after it is used?

If module linking is enabled (checkable on the config), then you'll have to, because module linking disallows duplicate imports.

Additionally, with module linking, a series of two-layer imports implicitly create a one-layer import of an instance:

(import "env" "x" ...)
(import "env" "y" ...)

;; ==>

(import "env" (instance (export "x" ...) (export "y" ...)))

But this means that the following is invalid:

(import "env" "x" ...)
(import "blah" ...)
(import "env" "y" ...)

because the "env" imports aren't back-to-back and so it desugars into multiple conflicting imports of an "env" instance.

So after you add an import with a different module name, you need to remove any imports from the previous module name from the available set.

If module linking is not enabled, then the imports may be reused (although we can leave this as a TODO for now, if you prefer, so that you don't have to implement both code paths right now).

[fitzgen]

Suggested change

	/// `(module name, field name, entity type)` describing each available import.
	/// each available import.

[fitzgen]

Let's keep all the publicly exposed AST types in the same module, rather than split between src/lib.rs and src/config.rs, so either:

• move everything to src/lib.rs
• move everything to src/config.rs
• or create src/ast.rs

soft preference for the third option.

[fitzgen]

In this case we can create a type section and push it onto self.initial_sections.

[matklad]

Making some progress here! it seems to work without module linking, and module linking currently fails with a bunch of validation errors ("aliased name g does not exist in instance" and such), today's quant run out before i figured what's an issue there.

[nagisa]

This can be closed now.