Will be support wasm's reference types spec?

compiler
1

wasm has a specification for referencing external memory. This allows the parameter type to be specified with the 'externref' WAT keyword. And allow proper mapping on the vm host side.

However, although rust supports wasm_import_module, it seems that the above specification is not supported yet. So it is difficult to pass an external memory object as an argument to wasm's extern function.

wasm-bindgen seems to be responding by appropriately patching the compiled wasm binaries to use the externref wat keyword. However, wasm-bindgen can be used limitedly in the web environment (because it is only interop for js). So it is still difficult to use the above specification when using wasm in a non-web environment.

So, I would like to summarize and ask again. Is there any plan to support rustc so that extern function (import function) parameters can be passed as externref type?

2

Has references types even been finalized in wasm? The repository you linked is archived, and last I knew it hadn't been finalized.

Ultimately this is a library-level construct, and would likely need to come from either the allocator in use or the runtime.

3

Has references types even been finalized in wasm? The repository you linked is archived, and last I knew it hadn't been finalized.

as far as I know, it is completed. please see below.

Most browsers are known to support it. https://webassembly.org/roadmap/

and rustc supports bulk-memory feature as a flag also, so I thought that this feature might be can be supported also.

4

Awesome! I haven't followed wasm too closely so I wasn't sure.

As I said, though, I think this is something that doesn't need strict integration with the language, as it would come from some library (be it an allocator or a runtime). Others will likely have better knowledge of this than me.

1 Like
5

What exactly would you want from rustc to "support" this?

Given that in wasm this is (as I guess based on vague memories) about opaque references to external memory which can't be read directly, you're probably looking for extern type. (And the ever used solutions on stable for pointer-to-unknown-type.) If so, perhaps this can serve as another motivator towards stabilizing extern type?

(I really want extern type to be available on stable. Yes I know all (most) of the issues it has in its current state.)

6

Yes, that's right. I can understand roughly what part you are worried about. Maybe I think Perhaps there were similar concerns in the proposal. But I have a short understanding this spec. I'll have to look for it.

7

https://wasmedge.org/book/en/extend/plugin/externref.html Could you take a look at this example?

Although it is c++, the memory of the type received by externref is recast and used as the original pointer type. Originally, you wouldn't be able to control memory objects outside of wasm.

8

What exactly would you want from rustc to "support" this?

When a pointer type is used as an argument in a function designated by wasm import module and extern "C", it is imagined that the externref keyword is attached to reference parameter type.

9

As far as I can tell, this is on the host side (i.e. Rust code using wasmtime to call into a wasm module). (Also, it's C, not C++.)

The client wasm is specifically prohibited from using the externref in any way but to pass it back to the embedder:

Reference types are opaque, meaning that neither their size nor their bit pattern can be observed.

This is fundamentally in conflict with exposing them to rust code, which can safely cast a pointer to an integer, or call mem::size_of_val(&externref).

1 Like
10

(Sorry for the late response. It's past working hours)

Reference types are opaque , meaning that neither their size nor their bit pattern can be observed.

I missed the spec description above. I understand that the spec of the externref type doesn't match rust's safly cast. That was good advice. thank you.

I will reconsider using the wasm_import_module extern within the exact limits.

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.