Change parsing to unify indirect call signatures with the same structure

[AndrewScheidecker]

This is meant to implement the changes discussed in WebAssembly/design#452.

This eliminates the need to declare an explicit type reference for indirectly-called functions, so I also tried to eliminate the redundancy and potential mismatch between a function's type reference and its directly declared parameters and result, so I made any function declaration implicitly introduce a type matching its directly declared parameters and result. But this approach makes an explicitly indexed type table much less useful, since you no longer have complete control over its contents. To resolve that, I removed the declarations, and references to, type table entries. The type table is created implicitly from the set of unique types used by func and call_indirect.

I also made the syntax slightly more uniform by defining a func_type production in the form (func_type ...), and using it in both call_indirect and import. I did not change func to use it, but I will submit another PR if people like this change.

[rossberg]

Hm, I'm not sure this is the best direction to go:

1. The type table is an integral part of a Wasm module AST (even after this change), so it should be possible to write it out explicitly, even if we add some convenience on top for adding entries implicitly.
2. In real code, there will likely be many indirect calls to functions of the same type, and being forced to repeat the type at each call site seems tedious.

[AndrewScheidecker]

The problem is that even without this change, function declarations can implicitly add entries to the type table, and can be mixed in with explicit type table entries:

(func (param i32) ...) ;; type index 0
(func (param i64) ...) ;; type index 1
(type (param i64))     ;; type index 2...or duplicate type error?

IMO the text format needs to either use entirely implicit type indices or entirely explicit type indices to avoid exposing text format specific semantics like that.

I personally prefer entirely implicit because it avoids the duplicate information in function declaration syntax, and it avoids giving the impression that you can meaningfully have multiple duplicate entries in the type table.

[rossberg]

I see, good point. I still don't think it's an option to not support an explicit type table -- the S-expression format is supposed to be a rendering of the AST, after all.

Maybe the best solution is to not make function definitions contribute/refer to the type table. It seems to introduce more complication than benefit at this point; most functions will not be called indirectly anyway, so why bloat the table with their types? @lukewagner, WDYT?

[lukewagner]

Good points. With unification, I agree that function definitions don't gain anything by being able to explicitly name an entry in the function table.

So is there any benefit then of allowing explicit (type) statements? Sure it lets you control the indices of signatures which could be useful for fuzz-type testing, but (1) you can get a fair degree of control by the order of function definitions (not total control if you want to simultaneously control function indices and signature indices, but enough to give fuzzers something to chew on), (2) the .wast format won't be able to hit every possible binary permutation; we'll need a binary fuzzer regardless (hopefully a shared one in the repo...). So I'd be fine cutting out the (type ...) declarations entirely and building the table implicitly from the uses.

[rossberg]

I think we decided not to support in-place type expressions, since it has no correspondence to the binary format. Closing.