[Parser] Fix Table64 parsing #7298
Conversation
src/ir/child-typer.h
Outdated
| // No table specified, so this is the default. | ||
| assert(!wasm.tables.empty()); | ||
| return wasm.tables[0].get(); | ||
| } |
There was a problem hiding this comment.
@tlively why is this necessary for tables but not memories? That is, when parsing some table.get instructions there is no name for the table. That is the case for e.g.
(func $table-get
i32.const 0
table.get
drop
)where there is no table specified. But this does not seem to be the case for memories, where the memory name is always non-null? (see notePointer, above, which does not need to be careful like noteTableIndex)
There was a problem hiding this comment.
Oops, just saw this question. Will take a look.
There was a problem hiding this comment.
Hmm, so when the table or memory index is left implicit in the parsed text, ParseDefsCtx::getTable and ParseDefsCtx::getMemory should be responsible for looking up the internal name of table or memory 0. So the table name should always exist here, and if it doesn't, the bug is earlier in the parser.
|
Ok, I found the bug - tables need to be explicitly set in the temporary objects in IRBuilder, and a few cases were missing. There was no way to notice that before this PR (and hence no way to test it). Fixed. |
We had some hardcoded i32 indexes, but the table might be table64.