Wasmtime GitHub notifications bot (Apr 09 2026 at 19:39): Wasmtime GitHub notifications bot (Apr 09 2026 at 19:39):fitzgen opened PR #13018 from fitzgen:const-eval-elems-follow-ups to bytecodealliance:main:
Addressing
https://github.com/bytecodealliance/wasmtime/pull/12985#pullrequestreview-4071913651<!--
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.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 09 2026 at 19:39):fitzgen requested alexcrichton for a review on PR #13018.
Wasmtime GitHub notifications bot (Apr 09 2026 at 19:39):fitzgen requested wasmtime-core-reviewers for a review on PR #13018.
Wasmtime GitHub notifications bot (Apr 09 2026 at 19:41):fitzgen updated PR #13018.
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:08):pchickey submitted PR review.
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:16):fitzgen added PR #13018 Small clean ups after evaluating element segments only once to the merge queue.
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:43):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:43):alexcrichton created PR review comment:
Given this type signature I think that this'll be MIRI-unsafe for a moving collector because it's not valid to mutate through the
NonNullpointer returned here, but I think moving collectors may want to mutate. Not that we can really write a test for that today, but something to keep in mind in the future perhaps
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:51):fitzgen removed PR #13018 Small clean ups after evaluating element segments only once from the merge queue.
Wasmtime GitHub notifications bot (Apr 09 2026 at 20:51):fitzgen merged PR #13018.
Wasmtime GitHub notifications bot (Apr 10 2026 at 16:26):fitzgen created PR review comment:
Would it be enough to make this
&mut self? Or would that still be problematic because the&mut selfborrow would end before the moving collector would write to the GC ref?
Wasmtime GitHub notifications bot (Apr 10 2026 at 16:26):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 10 2026 at 16:54):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 10 2026 at 16:54):alexcrichton created PR review comment:
&mut selfwould definitely give permissions for the returned raw pointer to be manipulated, and the problem is when the&mut selfgoes out of scope and moreso when the next&mutis taken on the same location. For example if you called this method twice the first pointer would be invalidated. Another example is that if you didlist[a].as_vmgc_ref_ptr()and thenlist[b].as_vmgc_ref_ptr()you'd invalidateaby creatingbsince that re-borrows the entire list which is the original borrowawas derived from.Overall though I think our only real defence here will be to ensure that Miri is running GC-related stuff, which I think it is already?
Last updated: Apr 12 2026 at 23:10 UTC