Value definitions: First time that parsing depends on previous section?

[primoly]

In #336 parsing of a value section depends on the contents of a component type section.

The types of all non primvaltypes refer to a typeidx. So a parser needs to look up the actual type in the component type section to know how to interpret the succeeding bytes.

component-model/design/mvp/Binary.md

Line 378 in 76cb955

val(i:<typeidx>) ::= v:<val(type-index-space[i])> => v

Is this the first time that the parsing of a section requires knowledge of the contents of a previous section?

It’s obviously already necessary for validation and execution, but I don’t think it has so far been the case for parsing in either Wasm modules or components, even for code sections. I believe that some Wasm consumers even use this property to do parsing and validation of sections in parallel which would no longer be possible, at least not when hitting a value section. I just wanted to check if I am correct.

I noticed this when working on adding support for value sections in wasmparser.

[lukewagner]

That's a really good observation and yes, I think you're right. I think this fact is somewhat essential to our goals of having an efficient, compact binary format for large values: the usual approach would be for us to insert an opcode-like discriminant into the byte stream so that we didn't have to refer back to the type to know what to decode next, but that's specifically what we're trying to avoid here.

This does make me think that perhaps we want to prefix each val() with a byte length that is validated to match what is decoded (just like we do for individual functions inside the code section). This would allow an early decoding pass to skip over the value contents, while still knowing the net effect on the value index space. It would also allow parallel decoding of values, just like with the function bodies.

@rvolosatovs what do you think? Importantly, this would be part of the top-level value rule, not part of the recursive val(t) rules, and thus just part of the "framing" and not impacting, e.g., the wrpc use case.

[rvolosatovs]

Makes perfect sense to me to prefix the encoded values with the byte length, let me update the PR!

[lukewagner]

Thanks @rvolosatovs; looks good to me. Does it make sense to you @primoly?

[primoly]

Yes, this makes sense. Thank you both very much.