The memory64 proposal was recently updated to include 64-bit tables in addition to 64-bit memories. Support for this extension has been implemented in wasm-tools and the main branch of Wasmtime is now using this version of wasm-tools. Wasmtime, however, does not yet implement the table64 extension and this is intended to track that.

Support for the table64 extension should be relatively simple in Wasmtime but it'll require a number of refactorings to switch indexing types and such. An (incomplete) list of implementation items to handle for this will be:

• Wasmtime's representation of table types should be updated with 64-bit limits and a table64 flag
• Methods taking indices in Wasmtime, such as this, should switch to u64 instead of u32.
• Libcalls involving tables, like this, should switch to u64 values.
• Translation of invoking libcalls should switch to using 64-bit values instead of 32-bit values. 32-bit tables will zero-extend indices to 64-bit values.
• Embedder API methods, like Table::get, should switch to u64.

More-or-less what I'm thinking is that a few key locations need to switch to u64 and then whack-a-mole is played with rustc to figure out where else needs to be switched to a u64. One point of note I'll say is that in general it's best to avoid as casts in this refactoring. Casting with as loses information in top bits if casting to a smaller size and that can accidentally cover up cases that should be out of bounds or trap. Instead u32::try_from or usize::try_from should be used where possible with appropriate handling of the error (e.g. bubbling it up or unwrapping with a comment as to why the unwrap is ok)