WASM function imports

[lqd]

Related to #29 is the issue of importing wasm functions from other wasm modules (or the environment, say, a JS function). What form should it take in our rust code ?

Some more info https://github.com/WebAssembly/design/blob/master/Modules.md#imports
Example https://github.com/WebAssembly/testsuite/blob/master/imports.wast#L2

Making it work similarly to the current FFI machinery would make sense, and this would look good I think:

#[link(name="spectest")]
extern {
    fn print(i: i32);
}

However, and this might be special treatment for the spectest module (probably @kripken can shed some light on this topic), it seems in this case — as seen in the linked example — the print function is overloaded. This might be a special case because exports are apparently required to have a unique name, IIUC meaning one might not be able to produce the same exports as the spectest module provides.

If this is to be supported — which is itself an interesting question, especially since printing is right now our "only" way to test — we might need to roll our own custom attribute à la:

extern {
    #[wasm_import(module="specttest", name="print")]
    fn print_i32(i: i32);

    #[wasm_import(module="specttest", name="print")]
    fn print_i64(i: i64);
}

There may be other attributes or language features more closely matching the semantics/requirements ? Maybe #[link_args] could be of use, etc.

@brson and @eholk what do you think ?

[eddyb]

@lqd #[link_name = "print"] is probably what you want.

[brson]

@eddyb's syntax looks right to me. It ultimately must work exactly like any other FFI import so that 'normal' Rust code can be compiled to wasm.

[lqd]

@eddyb @brson wasm has a two-level namespace, from the spec link: "All imports include two opaque names: a module name and an export name" — so we need to say which module to import, and then which function.

[eddyb]

@lqd But you already provided the solution for that:

#[link(name="spectest")]
extern {
    #[link_name = "print"]
    fn print_i32(i: i32);

    #[link_name = "print"]
    fn print_i64(i: i64);
}

[lqd]

@eddyb oh ok, so yes link + link_name is exactly what we need 😄

[kripken]

About overloading: yes, it's possible. The core issue is that when wasm imports a method, then on the web that is from JavaScript, which is not statically typed. So the function being called doesn't have types for params, etc. But wasm is typed, so (1) you must define those types for the imported function. And (2) you can import something multiple times (each to a different internal name), just because it seems arbitrary to limit that. As a result of (1)+(2) you can bind the same imported method to different internal import names that have different types, as in the examples here.

But this is indeed kind of a corner case. In practice, I'd expect to not need to care about stuff like this. spectest could have been written without it, it just happens to. On the web, it's also trivial to set up the imports on the JS side to avoid it. Bottom line, if this is annoying in any way for rust, I would just ignore it.

[lqd]

@kripken super clear, thank you.
By just making the #[link_name] optional, we get good ergonomics on the simple case of a single import, while also being able to support the more complex case of multiple imports of an untyped varargs extern (and spectest at the same time).