Text format for inline `shared` tables

[abrown]

Tables can be written in WAT in inline form and the addition of shared in the text format means that inline table expressions (e.g., (table <type> (elem ...))) are difficult to parse: the parser would potentially have to look past two tokens now, shared and i32|i64 to see if a type appears that indicates we should be parsing an inline format.

Here's an example of the problem:

(table shared i64 (ref null (shared func)) (elem (ref.null (shared func))))

Some options for what to do here:

• disallow inline table expressions with shared; after all, these can be expressed other ways
• force parsers to lookahead more tokens

[tlively]

Looking at the binaryen parser, it won't be too complicated to add support for this, so I'm inclined to prefer the option of forcing parsers to lookahead more tokens, but I can see that this might be more complicated for other parsers. How much trouble would this be?

FWIW, if we do decide to allow shared inline tables, we should update the Overview to say so; currently it does not.

[tlively]

Although looking at the previous threads proposal, it looks like the analogous abbreviation for memories was not extended to handle shared memories: https://github.com/WebAssembly/threads/blob/upstream-rebuild/document/core/text/modules.rst (although who know if that's the right branch).

[conrad-watt]

That's the right branch - if there's something I've potentially missed in the text format, would you be able to file an issue describing it in that repo?

[rossberg]

There may be a misunderstanding here, I don't think this requires look-ahead. Look-ahead arises when having to decide how to reduce a sequence of tokens that's already been parsed depending on tokens that have not yet parsed. That is not the case here. AFAICS, the grammar still is perfectly fine LALR(1), in fact even LL(1).

[tlively]

@conrad-watt, I filed https://github.com/WebAssembly/threads/issues/226.