wasmtime / PR #14184 Bump MSRV to 1.96.0 · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #14184 Bump MSRV to 1.96.0

Wasmtime GitHub notifications bot (Aug 20 2026 at 18:21):

alexcrichton opened PR #14184 from alexcrichton:bump-msrv to bytecodealliance:main:

Coupled with today's release of Rust 1.98.0

Wasmtime GitHub notifications bot (Aug 20 2026 at 18:21):

alexcrichton requested fitzgen for a review on PR #14184.

Wasmtime GitHub notifications bot (Aug 20 2026 at 18:21):

alexcrichton requested wasmtime-default-reviewers for a review on PR #14184.

Wasmtime GitHub notifications bot (Aug 20 2026 at 18:30):

:thumbs_up: pchickey submitted PR review.

Wasmtime GitHub notifications bot (Aug 20 2026 at 19:10):

alexcrichton requested wasmtime-core-reviewers for a review on PR #14184.

Wasmtime GitHub notifications bot (Aug 20 2026 at 19:10):

alexcrichton updated PR #14184.

Wasmtime GitHub notifications bot (Aug 20 2026 at 19:35):

alexcrichton commented on PR #14184:

Our MinGW target is broken with Rust 1.98.0 due to what I believe is https://github.com/rust-lang/rust/pull/148799. I've reached out on that PR to see if my latest commit here is the right approach, and in the meantime I'd prefer to not merge this until that's vetted.

Wasmtime GitHub notifications bot (Aug 20 2026 at 20:45):

ohadravid commented on PR #14184:

@alexcrichton I'll look into it tomorrow :mine:

Wasmtime GitHub notifications bot (Aug 20 2026 at 20:48):

alexcrichton commented on PR #14184:

Many thanks, and no rush!

Wasmtime GitHub notifications bot (Aug 20 2026 at 21:15):

ohadravid commented on PR #14184:

OK quick note: not sure why only on mingw, but I think the problem is that the thread_local/guard/windows.rs::enable hook in std is registered too late: instead of during the thread creation, it happens after a fiber is already running.

Later, the a different fiber is converted back to a thread and deletes the original fiber which triggers the FLS destructors prematurely.

I think a more correct solution is to also call the struct Guard; in Fiber::new (not sure if can be _moved_ entirely), but I'll be able to test this only tomorrow since I need to setup the env for this.

Also, I think std might want to avoid registering the hook when running in a fiber because of this - we already leak if the dtors are in a fiber, and it makes more sense to leak if we start in a fiber anyway. I'll add a test there and fix that.

Wasmtime GitHub notifications bot (Aug 20 2026 at 21:16):

ohadravid edited a comment on PR #14184:

OK quick note: not sure why only on mingw, but I think the problem is that the thread_local/guard/windows.rs::enable hook in std is registered too late: instead of during the thread creation, it happens after a fiber is already running.

Later, a different fiber is (1) converted back to a thread and (2) deletes the original fiber which triggers the FLS destructors prematurely.

I think a more correct solution is to also call the struct Guard; in Fiber::new (not sure if can be _moved_ entirely), but I'll be able to test this only tomorrow since I need to setup the env for this.

Also, I think std might want to avoid registering the hook when running in a fiber because of this - we already leak if the dtors are in a fiber, and it makes more sense to leak if we start in a fiber anyway. I'll add a test there and fix that.

Wasmtime GitHub notifications bot (Aug 21 2026 at 04:24):

ohadravid commented on PR #14184:

Actually, the fix here is the correct one for now, but I still need fix this in std :bug: .

In detail: we had issues with mingw in the original PR as well, because it doesn't have #[thread_local]. Because of that, we don't know if the enable hook was registered in the _thread_ already (which requires a #[thread_local] REGISTERED: Cell<bool>), so _every_ TLS access unconditionally set the the internal flag that triggers the dtors.
The fix will be to bail early if IsThreadAFiber in enable.

So, in summary: in mingw every TLS from a Fiber will cause dtors to be registered and incorrectly run when that Fiber is deleted if the deletion is not in a Fiber, so converting to Fiber in the drop is the best solution for now.

Wasmtime GitHub notifications bot (Aug 21 2026 at 04:24):

:thumbs_up: ohadravid submitted PR review.

Wasmtime GitHub notifications bot (Aug 21 2026 at 12:47):

ohadravid edited a comment on PR #14184:

Actually, the fix here is the correct one for now, but I still need fix this in std :bug: .

In detail: we had issues with mingw in the original PR as well, because it doesn't have #[thread_local]. Because of that, we don't know if the enable hook was registered in the _thread_ already (which requires a #[thread_local] REGISTERED: Cell<bool>), so _every_ TLS access unconditionally set the the internal flag that triggers the dtors.

This means that in mingw fibers are almost guaranteed to arm that internal flag and trigger the dtors. The result is that deleting the fiber when the caller is converted back to thread will trigger the dtors before thread exit, which is bug.
The fix will be to bail early if IsThreadAFiber in enable, which prevents this kind of behavior.

So, in summary: in mingw every TLS from a Fiber will cause dtors to be registered and incorrectly run when that Fiber is deleted if the deletion is not in a Fiber, so converting to Fiber in the drop is the best solution for now.

Wasmtime GitHub notifications bot (Aug 21 2026 at 14:42):

alexcrichton commented on PR #14184:

Thanks @ohadravid!

Wasmtime GitHub notifications bot (Aug 21 2026 at 14:42):

alexcrichton added PR #14184 Bump MSRV to 1.96.0 to the merge queue.

Wasmtime GitHub notifications bot (Aug 21 2026 at 15:09):

:check: alexcrichton merged PR #14184.

Wasmtime GitHub notifications bot (Aug 21 2026 at 15:09):

alexcrichton removed PR #14184 Bump MSRV to 1.96.0 from the merge queue.

Last updated: Aug 30 2026 at 09:07 UTC