consolidate unsafe code in concurrent.rs and friends

[dicej]

This adds a few abstractions to reduce the amount of unsafe code and make what remains easier to reason about locally (i.e. without relying as much on functions only being called in certain contexts, or on non-local safe code upholding invariants).

This introduces a StoreToken abstraction for witnessing the data type parameter T for a StoreContextMut<T> and later safely casting from a &mut dyn VMStore to a &mut StoreInner<T> within a closure by asserting that the StoreIds match.

This also eliminates various transmutes and other unsafe shenanigans to avoid a T: 'static bound since we've finally decided avoiding such a bound is impractical.

[dicej]

There are a bunch of outdated comments that need updating to match the new code; will work on that next.

[dicej]

Looks like it's going to take some work to convince CI to let me bump the MSRV to 1.85.0 given that it's newer than $CURRENT_STABLE minus 2; I'll probably just wait until 1.87.0 is released in a few days, which should satisfy it.

[alexcrichton]

If you want to test a bit sooner you can try decrementing this to 1 to increase the msrv to 1.85

[dicej]

@alexcrichton Does this failure mean anything to you? https://github.com/bytecodealliance/wasip3-prototyping/actions/runs/15052610459/job/42310963180

I can repro locally both on this branch and on main, so I believe it's unrelated to any of my changes, but I'm not sure why it's popping up now.

I thought maybe it could be related to me bumping the MSRV, but I can repro on Rust 1.84, too. EDIT: nevermind, I hit a different error on 1.84 and 1.86, which might be a qemu thing. So it does appear to be related to 1.87. Specifically, I get one test failure on 1.84 and 1.86, but two test failures on 1.87.

[dicej]

I think I'll just ignore the test on riscv for now with a TODO comment.

[dicej]

Oof, it's broken on s390x too, I guess.

[dicej]

CI and I are just not getting along today. Now the AddressSanitizer tests are failing with a bunch of leaks reported. Could be a real regression or could be another MSRV thing. I can't seem to use AddressSanitizer on my Linux/ARM64 machine, whether natively or via qemu, so I haven't been able to repro and bisect yet. Might need to borrow a Linux/x86_64 machine and try there.

[alexcrichton]

re riscv64/s390x, yeah that definitely looks like the msrv update, and is something we'll have to fix in upstream wasmtime

re asan, that may also be an msrv update with a newer llvm and a new ASAN build detecting something. Maybe threads related? Unsure, would need to try reproducing locally

(if possible I'd recommend decoupling the update to 1.87 and just update the msrv window to 1 to make the msrv here 1.85 while still using 1.86 as before today)

[dicej]

Okay; I just pushed an update to reduce msrv_range 🤞

[dicej]

Now the MinGW build is broken, both here and in #166. I'm going to just step slowly away from the computer for now.

[dicej]

Looks like the address sanitizer leak reports are a real regression and not related to the MSRV bump; they passed in #166 but failed here. I'll borrow a Linux/x86_64 device and see if I can repro and debug locally.

[dicej]

I've fixed some of the leaks flagged by AddressSanitizer; working on the others now.