Implement the table64 extension to the memory64 proposal

[alexcrichton]

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)

[ssnover]

I'm up for a game of whack-a-mole if you could assign me.

[alexcrichton]

If you're interested @ssnover some "getting started" tests can be enabled by commenting out this block now that the spec test suite has the table64 tests inside of it. Note though that those are not exhaustive tests so you'll likely want to write a test or two of your own as well.

[ssnover]

Hi @alexcrichton , sorry to go quiet on this issue after picking it up. I have a branch with most of the changes made, but I'm left with interactions around the i31ref type. Is there any equivalent being introduced by memory64 for an i63ref that is superseding or living alongside i31ref?