Does feature_block appear in text disassembly?

[eqrion]

The explainer describes feature_block as a 'decoding time' feature.

If a binary to text converter is run on a module, would this imply that the feature_block's present in the binary must be resolved (based off the supported features of the tool?) during the conversion to text? e.g. a features.supported would be printed as the resolved i32.const?

In addition, how would text to binary work? My understanding of the spec is that there is the abstract syntax, and conversions from the binary/text formats to/from the abstract syntax. If this is specified in the binary format and not in the abstract syntax, how can a conversion from text to binary be specified?

[tlively]

Resolving feature_block and friends at decode time is just one possibility, and I would expect engines to do that but not other tools that process Wasm modules. In particular, I would expect that we would specify a text format for feature_block and friends and that tools that convert between text and binary would default to preserving the conditional constructs.

As far as the specification goes, I think we could just specify the text fomat to also resolve features during translation to the abstract syntax, just like we would for the binary format. In practice non-engine tools would actually represent the conditional constructs in their internal representations, but that's not something the spec needs to cover.

[rossberg]

Is that even possible? A feature block can contain arbitrary sequences of bytes that a tool may not understand – and indeed this seems essential to the feature, because only this way backwards-compatibility is achieved with tools not (yet) aware of a new feature (for them, new opcodes are indistinguishable from garbage).

So I think any tool processing a feature block must always be prepared to encounter stuff it doesn't understand and handle that gracefully. It follows that it cannot generally decode the block or convert it to meaningful text.

[tlively]

Yes, tools must also do something in the case that they encounter an unknown feature. Where they do recognize the features, though, they can be more helpful. Thankfully what tools choose to do is mostly separate from what the spec mandates engines do AFAICT.

[titzer]

For decoding to text from binary, it seems like a feature_block could do one of these things:

1. Not interpret the bytes, but emit a (feature_block feature_set "binary string") expression
2. Interpret the bytes and decode them, emitting feature_block feature_set (exprs)), if the tool fully supports all features therein.
3. A combination of the two, emitting both.

The first and third option could be useful for tools to at least pass the bytes through uninterpreted.