Stream: git-wasmtime

Topic: wasmtime / PR #11688 disallow exiting a component instanc...

Wasmtime GitHub notifications bot (Sep 11 2025 at 21:34):

dicej requested alexcrichton for a review on PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 21:34):

dicej opened PR #11688 from dicej:fix-11676 to bytecodealliance:main:

This is a relatively recent change to the spec.

In order to check the may_leave flag in all the relevant intrinsics, I had to plumb the caller RuntimeComponentInstanceIndex through a bunch of trampolines that didn't previously need it, hence the large diff.

Note that I've added a slightly tweaked version of trap-in-post-return.wast and left the upstream version disabled in test-util/src/wast.rs due to #11683.

Fixes #11676.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Sep 11 2025 at 21:34):

dicej requested wasmtime-core-reviewers for a review on PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 21:34):

dicej requested wasmtime-compiler-reviewers for a review on PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 21:44):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 11 2025 at 22:05):

dicej commented on PR #11688:

@alexcrichton One of the CI failures is due to a test that calls resource.drop from a realloc function here, which now traps because we now consider calling resource.drop to be leaving the component instance. Should I update (or remove) that test, or do we need to make an exception in the spec for resource.drop? I.e. is this a scenario that needs to work for some reason?

Wasmtime GitHub notifications bot (Sep 11 2025 at 22:10):

alexcrichton commented on PR #11688:

I think we should preserve the high-level test of "cannot call resource.drop when actively borrowed" but you're right the test itself is now invalid because it fails for another reason.

Thinking about this test though there's a few things:

• One way to rewrite the test would be to start an async call with a borrow, then call resource.drop while it's running. That should result in a trap.
• The test is quite old and probably predates *.wast support and this test looks like it should be a *.wast rather than a in-rust test.
• I don't want to block this or place too much on you, so if you'd prefer feel free to update the test to assert a new error message and I'll come back to pick this up later.

Without async though I can't think of a valid way to call resource.drop while a borrow is active...

Wasmtime GitHub notifications bot (Sep 11 2025 at 22:12):

dicej commented on PR #11688:

Yeah, using async seems reasonable. I'll see what I can do.

Wasmtime GitHub notifications bot (Sep 11 2025 at 23:10):

dicej updated PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 23:12):

dicej updated PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 23:12):

dicej has enabled auto merge for PR #11688.

Wasmtime GitHub notifications bot (Sep 11 2025 at 23:49):

dicej merged PR #11688.

Last updated: Dec 06 2025 at 07:03 UTC