en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#c22b3cb9 Reuse Wasm linear memories code for GC heaps (#10503)* Reuse code for Wasm linear memories for GC heapsInstead of bespoke code paths and structures for Wasm GC, this commit makes itso that we now reuse VM structures like `VMMemoryDefinition` and bounds-checkinglogic. Notably, we also reuse all the associated bounds-checking optimizationsand, when possible, virtual-memory techniques to completely elide them.Furthermore, this commit adds support for growing GC heaps, reusing themachinery for growing memories, and makes it so that GC heaps always start outempty. This allows us to properly delay allocating the GC heap's storage until aGC object is actually allocated.Fixes #9350* fix c api compilation* use assert_contains* remove no-longer-necessary extra memory config from limiter tests* Helper for retry-after-maybe-async-gc in libcalls* Clean up some comments* fix wasmtime-fuzzing and no-gc compilation* fix examples* fix no-gc+compiler build* fix build without pooling allocator* fix +cranelift +gc-drc -gc-null builds* fix table hash key stability test* fix oracle usage of `ExternRef::new`* fix +gc -gc-null -gc-drc build* fix wasmtime-fuzzing* make `StorePtr` wrap a `NonNull`* Fix some doc tests* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc* fix things after rebase* Reorganize collection/growth methods for GC heap* rename BoundsCheck variants* fix cfg'ing of gc only code* Fix doc tests* fix one more gc cfg* disable GC heap OOM test on non-64-bit targets List of files: /wasmtime-44.0.1/tests/all/structs.rs Fri, 11 Apr 2025 21:15:55 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#cb235ecf Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)* Fix assertion in `PartialEq` for `RegisteredType` againIt is possible for two `WasmSubType`s to be equal to each other, as far as`derive(PartialEq)` is concerned, but still different from each other if theyare in different rec groups or even if they are at different indices within thesame rec group. The assertion mistakenly did not permit either of these,however.Fixes #9714* Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`sRather than canonicalizing them on demand in functions like`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it inone place, up front, so that it is very unlikely we miss anything. Doing thisinvolves changing some things from `ModuleInternedTypeIndex`es to`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch ofuses of those things need to unwrap the appropriate kind of type index at usagesites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtimeuses usage will unwrap `VMSharedTypeIndex`es). And it additionally requiredimplementing the `TypeTrace` trait for a handful of things to unlock theprovided `canonicalize_for_runtime_usage` trait method for those things.All this machinery is required to avoid an assertion failure in the regressiontest introduced in the previous commit, which was triggered because we werefailing to canonicalize type indices inside `ExternType`s for runtime usage onsome code paths. We shouldn't have to play that kind of whack-a-mole in thefuture, thanks to this new approach.* Fix a warning in no-default-features builds* Fix another warning in weird cfg builds List of files: /wasmtime-44.0.1/tests/all/structs.rs Fri, 14 Feb 2025 17:03:26 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#938c1777 Wasmtime: fix `PartialEq` implementation for `RegisteredType` (#10091)We were incorrectly checking whether they were in the same recgroup (i.e. whether the two `RegisteredType`s had the same `RecGroupEntry`)rather than whether they were actually the same type or not, even if they werein the same rec group.This fixes one of two issues reported in #9714 List of files: /wasmtime-44.0.1/tests/all/structs.rs Thu, 23 Jan 2025 15:23:05 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#9529243a Add support for initializing/getting/setting `funcref`s in GC structs from host APIs (#9454)* Add support for initializing/getting/setting `funcref`s in GC structs from host APIsWe implemented support for `funcref`s in both Wasm and host APIs for arrays, butsomehow only implemented support for `funcref`s in structs for compiled Wasmcode, and mistakenly forgot about them for structs and host APIs (and thingsthat use host APIs, such as const expressions).* fix clippy List of files: /wasmtime-44.0.1/tests/all/structs.rs Fri, 11 Oct 2024 01:36:43 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#a0442ea0 Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/tests/all/structs.rs Mon, 05 Aug 2024 09:59:59 +0000 Hamir Mahal <hamirmahal@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/structs.rs#f2e689cd 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/tests/all/structs.rs Thu, 11 Jul 2024 22:14:56 +0000 Nick Fitzgerald <fitzgen@gmail.com>