Make Rust work with emscripten

[brson]

I've spent some time poking at this problem and rustc now generates code that emscripten can translate, but the compiled javascript fails when it hits a runtime function. The next step is to start building the runtime using emcc as the compiler. Stub out all the things that don't build behind EMSCRIPTEN ifdefs.

Emscripten is adding a way to treat inline assembly as javascript, so all the parts of the runtime that don't build with emscripten can be implemented inline with javascript.

Alternately, we could reimplement the runtime piecemeal in javascript and not bother compiling it from C++ at all. This approach isn't recommended.

[bstrie]

See also #3608.

[catamorphism]

Would still be nice; not on any maturity milestone.

[msullivan]

Still would be nice, but is not very important. This should get easier, since a lot of the runtime is being rewritten in rust.

[kud1ing]

See also #7282

[bstrie]

Now that the runtime is written in Rust, how does that change the prospects for this bug? How hard would it be to get a runtimeless Hello World running through emscripten?

[kud1ing]

See

• https://github.com/thestinger/rust-core
• https://gist.github.com/klutzy/7819231

[brson]

It should not be particularly difficult to add really nice support for emscripten now. It already pretty much works with rust-core. In the compiler we need to add support for the proper target triple, set up the various target attributes correctly, then fence off the few parts of the runtime that can't currently work in js, threading and context switching.

Once 1:1 scheduling mode matures a bit more we may even be able to add support for tasks via web workers, though presently it would require a different message passing solution. Depending on what parallelism support gets added to js/emscripten we may eventually be able to support rust's message passing semantics precisely.

[thestinger]

@brson: I think #10780 would be the biggest blocker at the moment. Rust will output landing pads with calls to update the size used to do stack safety via LLVM's segmented stack support.

[thestinger]

Thanks to -Z no-landing-pads this now works fine! Adding explicit support for this to the standard library is possible, but most most isn't going to work anyway (files, tcp, udp, etc.) so I don't think it is necessary. If and when the standard library picks up freestanding support, it will start working and we can open more issues based on functionality we can map to JavaScript.

[alexcrichton]

If it's ok, I'd actually like to leave this open for now. I think that doing this would be a good step forward towards ensuring the standard library is extensible and able to run on any number of platforms.

I do agree that most of the work is probably done, and this will probably need libemscripten to provide emscripten-specific I/O, but I think that there may be enough snags hit along the way that this is worth leaving the issue open for (it's still an interesting project!)

[thestinger]

@alexcrichton: It won't be possible to provide the standard library's concurrency and I/O support for emscripten. At best, it could output to the console for stdout/stderr. I can't think of any things in the standard library that are going to be a good idea for an emscripten target but not a freestanding one, beyond a default allocator implementation.