Signatures of functions are not registered in wasmtime-api crate

[pepyakin]

A reproduction is quite simple, just try to extract a function from a table and call it:

use anyhow::{Context as _, Result};
use wasmtime::*;

fn main() -> Result<()> {
    let store = Store::default();

    let binary = wat::parse_str(
        r#"
          (module
            (func $f)

            (table (export "table") 1 1 anyfunc)
            (elem (i32.const 0) $f)
          )
        "#,
    )?;
    let module = Module::new(&store, &binary).context("> Error compiling module!")?;
    let instance = Instance::new(&store, &module, &[]).context("> Error instantiating module!")?;

    let f = instance
        .find_export_by_name("table")
        .unwrap()
        .table()
        .unwrap()
        .borrow()
        .get(0)
        .funcref()
        .unwrap()
        .clone();
    f.borrow().call(&[]).unwrap();

    Ok(())
}

Here is the stacktrace:

thread 'main' panicked at 'signature', src/libcore/option.rs:1185:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1028
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:188
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:205
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:464
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
  12: rust_begin_unwind
             at src/libstd/panicking.rs:302
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:139
  14: core::option::expect_failed
             at src/libcore/option.rs:1185
  15: core::option::Option<T>::expect
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/option.rs:345
  16: wasmtime::values::from_checked_anyfunc
  17: wasmtime::externals::get_table_item
  18: wasmtime::externals::Table::wasmtime_table_index
  19: wasmtime_table_repr::main
             at src/main.rs:20
  20: std::rt::lang_start::{{closure}}
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  21: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
  22: std::panicking::try::do_call
             at src/libstd/panicking.rs:287
  23: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  24: std::panicking::try
             at src/libstd/panicking.rs:265
  25: std::panic::catch_unwind
             at src/libstd/panic.rs:396
  26: std::rt::lang_start_internal
             at src/libstd/rt.rs:47
  27: std::rt::lang_start
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  28: wasmtime_table_repr::main

[pepyakin]

So my brief research revealed that anyfuncs from a table use VMSharedSignatureIndex for their signatures. They are basically a unique numbers generated for each seen ir::Signature. There is a reverse-lookup table of VMSharedSignatureIndex → ir::Signature but it is filled whenever we already have an existing concrete ir::Signature at hand.

My initial impression was that we could update Table::from_wasmtime_table to actually iterate over all functions present at the instantiation time, but for that we need to somehow lookup for the concrete signatures by their VMSharedSignatureIndex.

(Looking at the git history) @yurydelendik, what would be the way to solve this issue?

[yurydelendik]

@pepyakin yes, I'll take a look