Enable experimentation with out-of-tree libstd for wasm

[aidanhs]

One of the points of contention in #16 seems to be a disagreement about what should end up in the -unknown target.

If it was really easy to set up your own libstd to experiment with, it might lessen the urgency to get things into libstd and allow people to iterate out of tree (see my comment at rust-lang/rust#47102 (comment)).

First I'd like to document where I'm up to so far.

$ rustup default nightly-2018-01-15
$ git clone [email protected]:japaric/xargo.git && (cd xargs && cargo build)
$ git clone [email protected]:rust-lang/rust.git rust-wasm
$ cd rust-wasm
rust-wasm $ git checkout b71cbd
rust-wasm $ # some editing
rust-wasm $ git diff
diff --git a/src/etc/wasm32-shim.js b/src/etc/wasm32-shim.js
index d55083e..873b1de 100644
--- a/src/etc/wasm32-shim.js
+++ b/src/etc/wasm32-shim.js
@@ -113,3 +113,5 @@ for (var i = 0; i < module_imports.length; i++) {
 }
 
 let instance = new WebAssembly.Instance(m, imports);
+memory = instance.exports.memory;
+instance.exports.hi();
diff --git a/src/libstd/sys/wasm/mod.rs b/src/libstd/sys/wasm/mod.rs
index ba3d6a2..b57ce0e 100644
--- a/src/libstd/sys/wasm/mod.rs
+++ b/src/libstd/sys/wasm/mod.rs
@@ -36,7 +36,7 @@ use os::raw::c_char;
 // help receive debug output and see what's going on. In general this flag
 // currently controls "will we call out to our own defined shims in node.js",
 // and this flag should always be `false` for release builds.
-const DEBUG: bool = false;
+const DEBUG: bool = true;
 
 pub mod args;
 #[cfg(feature = "backtrace")]
rust-wasm $ cd ..
$ cargo new --bin mywasmtest
$ cd mywasmtest
mywasmtest $ vim src/main.rs
mywasmtest $ cat src/main.rs
fn main() {}

#[no_mangle]
pub fn hi() {
    println!("Hello, world!");
    let v = vec![1,2,3];
    println!("{:?}", v);
}
mywasmtest $ vim Xargo.toml
mywasmtest $ cat Xargo.toml
[dependencies]
std = { path = "../rust-wasm/src/libstd" }
mywasmtest $ XARGO_RUST_SRC=$(pwd)/../rust-wasm/src ../xargo/target/debug/xargo build --target wasm32-unknown-unknown --verbose --release
mywasmtest $ node ../rust-wasm/src/etc/wasm32-shim.js target/wasm32-unknown-unknown/release/mywasmtest.wasm                                                   
Hello, world!
[1, 2, 3]

i.e. it's possible to build your own working libstd wasm today with syscalls.

However, there are a few annoyances:

• xargo won't detect changes to libstd and rebuild, so I tend to resort to rm -rf ~/.xargo/lib/rustlib/wasm32-unknown-unknown/ - this means it unnecessarily rebuilds a bunch of downstream deps of libstd, and I have to remember to do it. See Xargo doesn't rebuild std automatically japaric/xargo#139.
• I have to clone the whole rust repo. Likewise, if some enterprising person wants to make available a libstd with particular wasm tweaks, they're probably going to do it by forking the whole rust repo and I have to depend on it as a git dep. But I don't care about having LLVM etc.

In my perfect world:

• xargo would detect changes to a path-dependency libstd. Possibly by just caching the Cargo.toml and just calling cargo build every time, letting cargo figure out what needs to be done.
• there would be a cargo rustlib fork command (if xargo were integrated into cargo it might take the form of cargo rustlib build) to build you a more minimal set of src/lib* directories from the rust repo. For example, you might do:

$ cargo rustlib new --commit b71cbd mywasmrustlibs && cd mywasmrustlibs
$ cargo rustlib fork libcore # would also grab any deps
$ cargo rustlib add libstd # add libstd to an existing set of libs
$ cargo rustlib update --commit bdda8d6 # download diffs from rust-lang/rust and try to apply

Which would then allow anyone to create their own repos of rustlibs and depend on them for applications.

[aidanhs]

Also related, the declaration that xargo is in maintenance mode and will probably be getting upstreamed at some point - japaric/xargo#193