Changes in arrayref.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/arrayref.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/arrayref.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/arrayref.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/arrayref.rs

c4be2d84 - Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)

Tue, 20 Aug 2024 19:34:28 +0000

Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arraysThis commit introduces the `wasmtime::ArrayRef` type and support for allocatingWasm GC arrays from the host. This commit does *not* add support for the`array.new` family of Wasm instructions; guests still cannot allocate Wasm GCobjects yet, but initial support should be pretty straightforward after thiscommit lands.The `ArrayRef` 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`ArrayRef`'s elements.Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocatinga Wasm GC array requires an `ArrayRefPre`, and this is motivated by the samereasons.* fix some doc tests and add docs for Func::wrap-style APIs* Add a comment about why we can't user `iter::repeat(elem).take(len)`* Fix some warnings in no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/disabled/arrayref.rs