Open alexcrichton opened 5 months ago
I'm up for a game of whack-a-mole if you could assign me.
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.
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
?
There is not an i63ref
, so no need to worry about it.
@ssnover Are you still working on it? If you’ve moved on to other things, I’d be happy to take it over and help move it forward.
Actually, the project I’m working on is blocked due to the lack of table64 support in Wasmtime. So, I’ll start implementing it anyway.
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:
table64
flagu64
instead ofu32
.u64
values.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 au64
. One point of note I'll say is that in general it's best to avoidas
casts in this refactoring. Casting withas
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. Insteadu32::try_from
orusize::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)