components: Validation of the start section conditionally defines the result as a value

[alexcrichton]

Currently values are conditionally defined in a module whether or not the start function returns a value. This is a little surprising to me (question for the spec layer less so here) that unit is specifically ignored, so we may want to confirm upstream that unit, and I guess only unit is supposed to be ignored?

Additionally the check here isn't 100% right in the sense that if a TypeId is used which points to unit (as-is the case today due to #600) then a value is defined, meaning that a value definition happens depending on how the function type itself is defined.

[alexcrichton]

As noted here there's the possibility of a good deal of simplification to wasmprinter to instead unconditionally define the result in the final index space. Currently wasmprinter has to otherwise plumb through all of the type information which gets particularly tricky with aliases.

My read of start definitions right now is that the result values are always appended to the index space, so I think spec-wise the current behavior should be ok to update.

[peterhuene]

I've been discussing this with Luke. We're going to codify, for now, that a value is always appended for the start function, even for unit returns.

This might be ammo for reopening the "component functions should allow for multi-return" discussion; if that ends up being implemented, then we'll need to maintain the same type information we do today in wasmprinter to figure out how many values get appended (or perhaps otherwise change the encoding to record the expected number of values appended directly in the start section?).

In the meantime, I think we can rip out the complex type tracking in wasmprinter and stop (incorrectly) conditionally appending a value in the validator.

[peterhuene]

Although we just realized that unconditionally appending a unit value from a start function would likely run afoul of the current validation requirement that all values be consumed (not yet enforced in wasmparser), causing a needless export of the value from the component to pass validation.

We're discussing this more in WebAssembly/component-model#41. I think we might be able to get away with a "result arity" in the start function section that would help simplier tools like wasmprinter not have to maintain so much type information just to figure out how to increment the current value count in the component.

[peterhuene]

This will be fixed with the upcoming implementation of the proposal changes.

[peterhuene]

This should be fixed with the latest wasm-tools as start functions are now multi-value result.