Clarify and regularize text format index parsing rules

[lukewagner]

This PR intends to resolve #648 by regularizing and more-clearly defining the text format rules for core- and component-level indices, identifiers and inline aliases. One nice thing with the changes in this PR is that there is now an explicit core-prefix(...) in the grammar at all the places where core might (when a plain $id is not used) get injected.

The test/syntax/indices.wast tries to test all the syntactic cases touched by this PR. The commented-out lines currently fail in wasm-tools and the rest pass as-is. This helps identify what the concrete delta from the status quo is. I didn't add any negative tests since I expect we'll need a phase-out process before rejecting anything that is accepted now.

PTAL @bvisness @alexcrichton

[alexcrichton]

Mind skimming over and double-checking some of the test-related changes on bytecodealliance/wasm-tools#2562?

[keithw]

Seeing this via the PR in wasm-tools; sorry for the late comment. If the component-model text format is being regularized, is this a good time to clarify the ordering requirements for symbolic identifiers?

In core Wasm, the use of an identifier can come before the identifier is bound:

(module
  (export "" (func $f))
  (func $f)
)

but this seems to be malformed in a component, in the sense that wasmparser's Parser rejects it (but I don't think there is explicit discussion of this in the Explainer yet or an assert_malformed test case):

(component
  (export "" (core module $m))
  (core module $m)
)

To me the more vexing case is something like:

(component
  (instance (export "" (instance 1)))
  (instance $i)
)

... which is accepted by wasmparser's Parser, but wasmprinter prints it out as:

(component
  (instance (;0;)
    (export "" (instance $i))
  )
  (instance $i (;1;))
)

which is rejected by wasmparser the next time (both before and after bytecodealliance/wasm-tools#2562).

tl;dr If attention is going into component WAT at the moment, is this the right time to lock down what is considered well-formed? This could help get to a place where all well-formed components successfully roundtrip through wasmparser->wasmprinter->wasmparser. (We got there for core modules in bytecodealliance/wasm-tools#2148 .)

[alexcrichton]

I'd consider both of those technically bugs in wast, wasm-tools's text-to-binary-stage. Components are core wasm are subtly different here where core wasm can sort of have everything reordered and items like functions, can refer to items defined after them. For components this isn't the case, nothing is reordered in the text format (it all goes through as-is to the binary format) and definitions cannot refer to future definitions. This means that text-format-resolution for core wasm modules does a pass of "register all the identifiers" followed by "now go resolve what everything points to". For components though (and this is the buggy part) it instead only registers identifiers as their visited without this initial pre-pass. That's why the module with an integer index is parsed by the text parser and prints, but can't re-parse (as printing shares a lot of its infrastructure with core wasm and components).

Basically a long way of saying that I think this is just a bug in wast. It should visit all identifiers to assign indices first before actually resolving names. I think that would resolve all the components above. They'd still all be invalid components, but would round-trip through parsing.