rust stdlib for wasm32-wasi · rust-toolchain

Probably this is not the right forum to ask, but it's in a section called rust-toolchain so i'll take advantage of that.

What's the story behind stdlib support for wasm32-wasi targets? It seems to me that while the target is available in stable rust, the stdlib implementation is by far not stable, as it now assumes that whatever we build with a "latest" rust toolchain we deployed on a modern VM that handles those functions.

Case in point, memcpy support doesn't exist in WASM as an intrinsic. Once it's added, the rust toolchain will assumes that the WASM VMs have supports for a wasi-function that's called whenever that operation is needed (or threads, or any other example that's similar).

But that means that newly compiled rust wasm32-wasi programs will not work anymore on old VMs that don't have those wasi methods or wasm capabilities (e.g. atomics later) exposed.

So my question here is what does it mean for wasm32-wasi to be in stable rust as a target?
What's the plan to evolve it to have more features in a stable way? (is there one?)
Is there some place where I can read these things as right now this differs in terms of support of _stability_ guarantees stable rust targets.

Dan Gohman (Mar 11 2021 at 13:51):

For adding new wasm instructions, the similar is somewhat analogous to how x86 adds new instructions all the time too.

Dan Gohman (Mar 11 2021 at 13:52):

Rust has things like -C target-feature=+avx2 to let users specify which kind of platform to target, and wasm targets will have similar things, as we add the memcpy operator and other things.

Dan Gohman (Mar 11 2021 at 13:54):

Then there's the question of what the defaults should be. This is a complex decision even on mature targets like x86, and it'll be somewhat complex on wasm too.

Alexandru Ene (Mar 11 2021 at 13:54):

Does this mean that the defaults are whatever's now in rust's stdlib implementation for wasm32-wasi (given it's in stable?)

Dan Gohman (Mar 11 2021 at 13:55):

That's the default today. My understanding is that these defaults can change over time, even for mature platforms like x86.

Alexandru Ene (Mar 11 2021 at 13:56):

Is there some place where i can read about this process? I didn't find anything on github

Dan Gohman (Mar 11 2021 at 13:57):

For wasm targets, there's some discussion (eg. here) about how we should set defaults, and I think the high-level consensus is "when features are standardized (phase 4) and all "major" engines support them", for some definitinon of "major"

Enabling features by default in LLVM · Issue #158 · WebAssembly/tool-conventions

I know we discussed this a while ago, but I forget what exactly we came up with @aheejin @dschuff @sbc100 @sunfishcode. IIRC, it wasn't too different from enabling new features once the followi...

Alexandru Ene (Mar 11 2021 at 19:43):

Ok, thanks I'll continue this discussion there, because it's making things a bit (significantly) harder for IOT -type use-cases to change defaults at this type of pace

Alexandru Ene (Mar 11 2021 at 19:46):

To be honest, the WASM instructions are slightly less of an issue, the worrying part to me is the WASI component that's under a "preview" namespace, but in stable rust :grinning:

Alexandru Ene (Mar 11 2021 at 19:47):

And it has a history of changing that namespace from unstable-.... to preview even tho some VMs didn't change the "env" where the wasi functios were exported under

Dan Gohman (Mar 11 2021 at 19:47):

Dan Gohman (Mar 11 2021 at 19:48):

We get a lot of feedback from people about this, and perhaps in 2021 people aren't used to seeing systems at the very beginning of being designed, but that's what WASI is.

Alexandru Ene (Mar 11 2021 at 19:48):

I understand that, that's clear, what's not clear is what it means for rustc to allow these types of "evolving" platforms be in stable rust :smile:

Dan Gohman (Mar 11 2021 at 19:48):

Is there something you're looking to do that this makes harder, or is it just about communication?

Alexandru Ene (Mar 11 2021 at 19:49):

To be honest, i don't m ind the evolution too much for these use-cases, what would be really nice would be for stdlib to rustc basically and have guarantees around how they may change.
now this means i am tied to some rustc version that happened to ship with a lib that's supported by some targets people may be interested in

Alexandru Ene (Mar 11 2021 at 19:49):

so if i upgrade rust now, it's a die roll if wasm32-wasi still works in this version exactly like in the last version basically, even tho that platform is a "stable" rust target

Alexandru Ene (Mar 11 2021 at 19:50):

As the minimum req. features from WASM engines may evolve from a release to another

Dan Gohman (Mar 11 2021 at 19:51):

At a first glance, the only way I see that we could do that would be to just remove wasm32-wasi from stable Rust

Alexandru Ene (Mar 11 2021 at 19:51):

An alternative is allowing users of rust to specify the stdlib version they are intereted to use. That would also solve it (predictability is also nice), but now users in this scenario can't use new language features because the stdlib ships together with new rustc releases without a way to use a different one.

Dan Gohman (Mar 11 2021 at 19:53):

Part of the reason WASI isn't evolving at the pace that everyone would like it to is that we have limited development resources.

Dan Gohman (Mar 11 2021 at 19:53):

Alexandru Ene (Mar 11 2021 at 19:53):

I would be really interested to contribute, but. haven't really found a lot of ways on how to contribute.

Alexandru Ene (Mar 11 2021 at 19:53):

Most meetings i've seen scheduled are focused on wasm itself (e.g. rust wasm group) and not wasi

Dan Gohman (Mar 11 2021 at 19:54):

Well, let's say we wanted a feature like a rustc command-line flag to select which WASI snapshot is in use

Dan Gohman (Mar 11 2021 at 19:55):

Alexandru Ene (Mar 11 2021 at 19:56):

Dan Gohman (Mar 11 2021 at 19:56):

That's something where, if someone wanted to work on it, I'd say, let's touch base before anyone goes off and does a bunch of work, but it's mostly just a bunch of work :-)

Alexandru Ene (Mar 11 2021 at 19:57):

Dan Gohman (Mar 11 2021 at 19:58):

That's a good question. I myself am not super familiar with the Rust RFC landscape

Dan Gohman (Mar 11 2021 at 19:58):

Alexandru Ene (Mar 11 2021 at 19:59):

Alexandru Ene (Mar 11 2021 at 20:00):

Ok, let me start a discussion with them on this before starting to write a RFC, as an issue may be sufficient

Dan Gohman (Mar 11 2021 at 20:01):

Alexandru Ene (Mar 11 2021 at 20:03):

Library team

A language empowering everyone to build reliable and efficient software.