Changes in structref.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/structref.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/structref.rs

a727985c - Enable warnings if `gc` is disabled (#10149)

Thu, 30 Jan 2025 16:55:15 +0000

Enable warnings if `gc` is disabled (#10149)* Enable warnings if `gc` is disabledContinuation of work in #10131. This additionally handles turning off`gc-null` and `gc-drc` and the various combinations within.* Fix some more warnings* Fix a feature combo build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/structref.rs

de1ad347 - Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

Thu, 09 Jan 2025 23:13:22 +0000

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)* Enable `impl-trait-overcaptures` 2024 transition lintThis lint detects cases where returning `impl Trait` will workdifferently in 2024 than in the current 2021 edition. Ambiguities areresolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean thesame thing in both editions.* Fix some more `impl Trait` returns* Tighten bounds on settings `iter`* Fix build on 1.82.0* Fix another capture on MSRV List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/structref.rs

f2e689cd - Introduce `wasmtime::StructRef` and allocating Wasm GC structs (#8933)

Thu, 11 Jul 2024 22:14:56 +0000

Introduce `wasmtime::StructRef` and allocating Wasm GC structs (#8933)* Introduce `wasmtime::StructRef` and allocating Wasm GC structsThis commit introduces the `wasmtime::StructRef` type and support for allocatingWasm GC structs from the host. This commit does *not* add support for the`struct.new` family of Wasm instructions; guests still cannot allocate Wasm GCobjects yet, but initial support should be pretty straightforward after thiscommit lands.The `StructRef` type has everything you expect from other value types in the`wasmtime` crate:* A method to get its type or check whether it matches a given type* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style APIs* The ability to upcast it into an `AnyRef` and to do checked downcasts in the opposite directionThere are, additionally, methods for getting, setting, and enumerating a`StructRef`'s fields.To allocate a `StructRef`, we need proof that the struct type we are allocatingis being kept alive for the duration that the allocation may live. This isrequired for many reasons, but a basic example is getting a struct instance'stype from the embedder API: this does a type-index-to-`StructType` lookup andconversion and if the type wasn't kept alive, then the type-index lookup willresult in what is logically a use-after-free bug. This won't be a problem forWasm guests (when we get around to implementing allocation for them) since theirmodule defines the type, the store holds onto its instances' modules, and theallocation cannot outlive the store. For the host, we need another method ofkeeping the object's type alive, since it might be that the host defined thetype and there is no module that also defined it, let alone such a module thatis being kept alive in the store.The solution to the struct-type-lifetime problem that this commit implements forhosts is for the store to hold a hash set of `RegisteredType`s specifically forobjects which were allocated via the embedder API. But we also don't want to doa hash lookup on every allocation, so we also implement a `StructRefPre` type. A`StructRefPre` is proof that the embedder has inserted a `StructType`'s inner`RegisteredType` into a store. Structurally, it is a pair of the struct type anda store id. All `StructRef` allocation methods require a `StructRefPre`argument, which does a fast store id check, rather than a whole hash tableinsertion.I opted to require `StructRefPre` in all allocation cases -- even though thishas the downside of always forcing callers to create one before they allocate,even if they are only allocating a single object -- because of tworeasons. First, this avoids needing to define duplicate methods, with andwithout a `StructRefPre` argument. Second, this avoids a performance footgun inthe API where users don't realize that they *can* avoid extra work by creating asingle `StructRefPre` and then using it multiple times. Anecdotally, I've heardmultiple people complain about instantiation being slower than advertised but itturns out they weren't using `InstancePre`, and I'd like to avoid that situationfor allocation if we can.* Move `allow(missing_docs)` up to `gc::disabled` module instead of each `impl`* Rename `cast` to `unchecked_cast`* fix `GcHeapOutOfMemory` error example in doc example* document additional error case for `StructRef::new`* Use `unpack` method instead of open-coding it* deallocate on failed initialization* Refactor field access methods to share more codeAnd define `fields()` in terms of `field()` rather than the other way around.* Add upcast methods from structref to anyref* Remove duplicate type checking and add clarifying comments about initializing vs writing fields* make the `PodValType` trait safe* fix benchmarks build* prtest:full* add miri ignores to new tests that call into wasm List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/structref.rs