Skip to content

Clarify and regularize text format index parsing rules#655

Open
lukewagner wants to merge 1 commit into
mainfrom
tweak-id-syntax
Open

Clarify and regularize text format index parsing rules#655
lukewagner wants to merge 1 commit into
mainfrom
tweak-id-syntax

Conversation

@lukewagner

Copy link
Copy Markdown
Member

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

Comment thread design/mvp/Explainer.md
Comment thread design/mvp/Explainer.md
Comment thread design/mvp/Explainer.md Outdated
Comment thread design/mvp/Explainer.md Outdated
@lukewagner lukewagner force-pushed the tweak-id-syntax branch 6 times, most recently from 9476a8f to 4924fce Compare July 8, 2026 18:23
@alexcrichton

Copy link
Copy Markdown
Collaborator

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

@keithw

keithw commented Jul 10, 2026

Copy link
Copy Markdown
Member

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 .)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Why is it (dtor (func n)) instead of (dtor (core func n))?

4 participants