Support for multi-value wasm

[fitzgen]

This relies on some PRs to other repos landing and/or being published to crates.io, nonetheless I think it is otherwise ready to land and ready for review.

r? @sunfishcode

TODO:

• cut a new wasmparser release that includes https://github.com/yurydelendik/wasmparser.rs/pull/135 (cc @yurydelendik)

• cut a new cranelift-wasm release that includes:

  • cranelift-wasm: Create ModuleTranslationState and polish API a little cranelift#1111

  • deps: bump wasmparser dependency to 0.39.2 cranelift#1112

• remove the TEMP commit and use those new releases in this PR instead

[fitzgen]

Also r? @alexcrichton on the wasmtime-interface-types commit

[alexcrichton]

Technically I think all the code for wasm-interface-types could stay as-is to work with older modules, but I like the idea better about being aggresive for removing older functionality

[fitzgen]

All the PRs in cranelift that this depends on have merged, so now we just need to

• cut a new cranelift release to get bytecodealliance/cranelift@995a877, and
• remove the temp commit in this PR!

[fitzgen]

Ok, all the blockers have been taken care of! Just rebased and this should be ready to go (assuming CI is green and review is positive).

+cc @abrown

[fitzgen]

This is getting failures on windows that I don't understand and unfortunately I don't have a windows machine with me right now:

failures:

---- Cranelift::multi_value::br stdout ----
thread 'Cranelift::multi_value::br' panicked at 'error running wast file: WastFileError { filename: "spec_testsuite\\proposals\\multi-value\\br.wast", line: 3, error: Action(Setup(Compile(Codegen(Verifier(VerifierErrors([VerifierError { location: inst4, message: "ABI expects v2 at stack offset 32, got %xmm1" }])))))) }', src\libcore\result.rs:1084:5
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.34\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\sys_common\backtrace.rs:47
   2: std::sys_common::backtrace::print
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\sys_common\backtrace.rs:36
   3: std::panicking::default_hook::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:200
   4: std::panicking::default_hook
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:211
   5: std::panicking::rust_panic_with_hook
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:477
   6: std::panicking::continue_panic_fmt
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:384
   7: std::panicking::rust_begin_panic
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:311
   8: core::panicking::panic_fmt
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libcore\panicking.rs:85
   9: core::result::unwrap_failed
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libcore\result.rs:1084
  10: core::result::Result<(), wasmtime_wast::wast::WastFileError>::expect<(),wasmtime_wast::wast::WastFileError>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libcore\result.rs:879
  11: wast_testsuites::Cranelift::multi_value::br
             at .\target\debug\build\wasmtime-c7e22e53f6f6ebd9\out\wast_testsuite_tests.rs:1157
  12: wast_testsuites::Cranelift::multi_value::br::{{closure}}
             at .\target\debug\build\wasmtime-c7e22e53f6f6ebd9\out\wast_testsuite_tests.rs:1149
  13: core::ops::function::FnOnce::call_once<closure-0,()>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libcore\ops\function.rs:235
  14: alloc::boxed::{{impl}}::call_once<(),FnOnce<()>>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\liballoc\boxed.rs:787
  15: panic_unwind::__rust_maybe_catch_panic
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libpanic_unwind\lib.rs:80
  16: std::panicking::try
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd\panicking.rs:275
  17: std::panic::catch_unwind
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd\panic.rs:394
  18: test::run_test::run_test_inner::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libtest\lib.rs:1408
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[abrown]

Hm, I'm not sure but there may be a way to tell clif-util what calling convention you want to use by setting the triple (using the --target option): if you figure out what Wasm snippet causes this failure and then feed that to clif-util compile with whatever triple invokes the Windows calling convention then we could reproduce this on all machines.

[fitzgen]

Ah ok, I was finally able to reproduce the issues with windows. (I was previously passing -t so it wasn't actually getting legalized and all that... d'oh)

The problem is that, unlike sys v, windows fast call doesn't give us a few registers that we can fit extra return values in without implementing full blown return pointers.

I think the best course of action is to disable the multi-value spec tests on windows for now, land this, and then continue pursuing the cranelift PR for "real" multi-value.

Will update the PR in a second.

[fitzgen]

Alright CI is green!

[sunfishcode]

Looks great!

[sunfishcode]

Woohoo!