Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)

* Generalize `VMGcObjectDataMut` for immutable GC object accesses too

This makes it generic over a `T` and then shared+i

Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)

* Generalize `VMGcObjectDataMut` for immutable GC object accesses too

This makes it generic over a `T` and then shared+immutable accesses are bound by
`T: AsRef<[u8]>` and exclusive+mutable accesses are bound by `T: AsMut<[u8]>`.

This allows reusing these accessors in more places in the future, and means
there are fewer places to bounds check accesses and remember to do little-endian
conversion and all that.

* Make `VMGcObjectData` a fancy unsized newtype

* fix no-gc builds

show more ...

Add the "null" garbage collector (#9484)

* Add the "null" garbage collector

The null collector does not actually collect any garbage, it simply
bump-allocates until the heap is exhausted, at which

Add the "null" garbage collector (#9484)

* Add the "null" garbage collector

The null collector does not actually collect any garbage, it simply
bump-allocates until the heap is exhausted, at which point further allocation
attempts will fail. It does not require any GC barriers.

Users can configure which collector to use via the `wasmtime::Config::collector`
method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration,
similar to the `wasmtime::Strategy` enumeration but for choosing a collector
rather than a compiler, additionally has a table summarizing the properties and
characteristics of our current set of collector implementations.

Finally, we also run `.wast` tests that exercise GC types under both the DRC and
null collectors. I tried to avoid running tests that are not related to GC under
both configurations just to avoid a combinatorial blow up.

* cargo fmt

* fix +gc -gc-null -gc-drc build

* Fix some warnings in various cargo feature combo builds

* Fix some more warnings in certain build configs

* Fix unit tests for null GC

* Fill in some placeholder comments that I forgot to write

* Fix issues where we ask for a GC store when we don't actually need one

Which was causing test failures, since we no longer return a GC store with a
dummy heap.

* Add fuzzing config support for different collectors

* address review feedback

* fix cmake tests

* Fix test compilation after rebase

* Fix GC tests under MIRI

show more ...

Implement the `array.copy` Wasm GC instruction (#9389)

* Implement the `array.copy` Wasm GC instruction

This also involved fixing some `VMGcRef` initialization and GC barrier code for
globals. That

Implement the `array.copy` Wasm GC instruction (#9389)

* Implement the `array.copy` Wasm GC instruction

This also involved fixing some `VMGcRef` initialization and GC barrier code for
globals. That in turn involved making global initialization fallible, which
meant that it needed to be pulled out of `vmctx` initialization and put into
instance initialization.

Co-Authored-By: Alex Crichton <[email protected]>

* fix compile error due to code moving where a trait method was no longer in scope

* use the result of `MaybeUninit::write`

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Implement most `array.*` instructions for the GC proposal (#9326)

* Implement most `array.*` instructions for the GC proposal

This does not implement `array.copy` and `array.init_elem` yet, but imp

Implement most `array.*` instructions for the GC proposal (#9326)

* Implement most `array.*` instructions for the GC proposal

This does not implement `array.copy` and `array.init_elem` yet, but implements
all other `array.*` instructions:

* `array.new`
* `array.new_fixed`
* `array.new_default`
* `array.new_data`
* `array.new_elem`
* `array.fill`
* `array.init_data`
* `array.len`
* `array.get`
* `array.get_s`
* `array.get_u`
* `array.set`

Note that the initial plumbing for `array.{copy,init_elem}` is in place, but the
instructions themselves are not implemented yet.

* Fix no-gc builds

* Fix some clippy warnings

* cargo fmt

* Fix another clippy error

* Fix more clippy errors

* Remove debug logging

* Add array.fill helper

* exit scope even on panic

show more ...

Always keep data inside GC objects in little-endian order (#9320)

* Always keep data inside GC objects in little-endian order

We were previously using native-endian on the assumption that it wasn't

Always keep data inside GC objects in little-endian order (#9320)

* Always keep data inside GC objects in little-endian order

We were previously using native-endian on the assumption that it wasn't
observable to Wasm, but it turns out that assumption isn't true. The
`array.[init,new]_data` instructions take a data segment and copy it into an
array. The arrays are not limited to `i8` arrays; they can be any non-reference
type, so the endianness is visible, and Wasm requires little endian.

* Use little-endian stores for initializing GC fields as well

Not just reading and writing to already-initialized fields.

* Update disas tests

show more ...

Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)

* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions

* fix no-gc builds

Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)

* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions

* fix no-gc builds

* wrap const evaluation in `AutoAssertNoGc`

* add assertions that we access `VMGcRef`s in native-endian

* fix an endian mismatch bug between compiled wasm code and host code

show more ...

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

* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays

This commit introduces the `wasmtime::ArrayRef` type and support

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

* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays

This commit introduces the `wasmtime::ArrayRef` type and support for allocating
Wasm GC arrays from the host. This commit does *not* add support for the
`array.new` family of Wasm instructions; guests still cannot allocate Wasm GC
objects yet, but initial support should be pretty straightforward after this
commit 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 direction

There are, additionally, methods for getting, setting, and enumerating a
`ArrayRef`'s elements.

Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocating
a Wasm GC array requires an `ArrayRefPre`, and this is motivated by the same
reasons.

* 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

show more ...