Upgrade wasmtime from 24.0.6 -> 42.0.1

[leonm1]

Built off of #501.

[PiotrSikora]

What's the reason for enabling "gc-drc" here?

[leonm1]

After updating wasmtime, it fails to load any modules when the gc feature is enabled and neither gc-drc nor gc-null is enabled. It prints an error message saying one of those flags is required.

I believe gc-null was introduced in v27: https://bytecodealliance.org/articles/wasmtime-27.0

[PiotrSikora]

I saw this error in my local testing (outside of C++ Host), but only when I tried to enable GC support or Wasm exceptions.

Wasmtime can execute plugins perfectly fine with or without the "gc" feature, and without either "gc-drc" or "gc-null", if you don't enable the aforementioned options.

Also, if I remove "gc-drc" here and in bazel/external/wasmtime.BUILD, then all tests in this repo pass with --define engine=wasmtime, so I'm not sure where do you see this error?

[leonm1]

Also, if I remove "gc-drc" here and in bazel/external/wasmtime.BUILD, then all tests in this repo pass with --define engine=wasmtime, so I'm not sure where do you see this error?

Did you also run bazel run //bazel/cargo/wasmtime:crates_vendor -- --repin? That will actuate the feature tag change in the Cargo.toml. After that, I get the following panic:

thread '<unnamed>' (14) panicked at external/cu__wasmtime-42.0.1/src/engine.rs:88:41:
called `Result::unwrap()` on an `Err` value: cannot create an engine with GC support when none of the collectors are available; enable one of the following features: `gc-drc`, `gc-null`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread '<unnamed>' (14) panicked at library/core/src/panicking.rs:225:5:
panic in a function that cannot unwind
stack backtrace:
   0:     0x559b9656aad2 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1851ca2a850bd9a9
   1:     0x559b9659a667 - core::fmt::write::h22467d3ad5dd5554
   2:     0x559b9651de96 - std::io::Write::write_fmt::h5e3b6a876f7a20bf
   3:     0x559b9653b234 - std::panicking::default_hook::{{closure}}::he43c3ac33dfa4b50
   4:     0x559b9653b094 - std::panicking::default_hook::hd124da54acf1152f
   5:     0x559b9653b51b - std::panicking::panic_with_hook::h9b5f1f19954f65a8
   6:     0x559b9653b31a - std::panicking::panic_handler::{{closure}}::hf431df8c849ee0d6
   7:     0x559b96532fb9 - std::sys::backtrace::__rust_end_short_backtrace::hf97362b31a346cc0
   8:     0x559b9650fdad - __rustc[9e6a08e89e4b9111]::rust_begin_unwind
   9:     0x559b965a9add - core::panicking::panic_nounwind_fmt::hf349702e3facb1fd
  10:     0x559b965a9a1b - core::panicking::panic_nounwind::h9a55331e46709e5f
  11:     0x559b965a9be7 - core::panicking::panic_cannot_unwind::h9d41c6c1d0e0d4e5
  12:     0x559b9503397a - wasmtime_wasm_engine_new
  13:     0x559b94ff7377 - _ZN10proxy_wasm8wasmtime6engineEv
  14:     0x559b94ff7420 - _ZN10proxy_wasm8wasmtime8Wasmtime9initStoreEv
  15:     0x559b94ff7493 - _ZN10proxy_wasm8wasmtime8Wasmtime4loadENSt3__117basic_string_viewIcNS2_11char_traitsIcEEEES6_RKNS2_13unordered_mapIjNS2_12basic_stringIcS5_NS2_9allocatorIcEEEENS2_4hashIjEENS2_8equal_toIjEENS9_INS2_4pairIKjSB_EEEEEE
  16:     0x559b94f46730 - _ZN10proxy_wasm8WasmBase4loadERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEb
  17:     0x559b94e6f3e5 - _ZN10proxy_wasm12_GLOBAL__N_126TestVm_RandomTooLarge_Test8TestBodyEv
  18:     0x559b965f9184 - _ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc
  19:     0x559b965dadf6 - _ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc
  20:     0x559b965c1c97 - _ZN7testing4Test3RunEv
  21:     0x559b965c2581 - _ZN7testing8TestInfo3RunEv
  22:     0x559b965c2d1a - _ZN7testing9TestSuite3RunEv
  23:     0x559b965d03f5 - _ZN7testing8internal12UnitTestImpl11RunAllTestsEv
  24:     0x559b965fbc84 - _ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc
  25:     0x559b965dd1c6 - _ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc
  26:     0x559b965cfd33 - _ZN7testing8UnitTest3RunEv
  27:     0x559b965b2621 - _Z13RUN_ALL_TESTSv
  28:     0x559b965b25fb - main
  29:     0x7f86c6dc4ca8 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  30:     0x7f86c6dc4d65 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  31:     0x559b94e67fa1 - _start
thread caused non-unwinding panic. aborting.
================================================================================

Since the wasmtime-c-api-impl crate specifies wasmtime's features explcitly, I don't believe there's a way to remove the gc feature currently. I can send a PR to remove that (since wasmtime-c-api-impl already permits setting gc transitively via its own gc feature), but I don't think it'll make it into this release.