Add a new wasm32-unknown-wasi target #59464

alexcrichton · 2019-03-27T16:23:34Z

This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
wasm32-unknown-wasi target is intended to be a WebAssembly target
which matches the WASI proposal recently announced. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.

The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:

Instant::now and SystemTime::now work
env::args is hooked up
env::vars will look up environment variables
println! will print to standard out
process::{exit, abort} should be hooked up appropriately

None of these APIs can work natively on the wasm32-unknown-unknown
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is wasmtime, but more
will surely emerge!

In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's also to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like read and write are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should std::fs::File
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.

A WasiFd sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like std::fs::File if we bind wasi file
descriptors exactly.

Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like open (as opposed to the
relative openat inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and read/write of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.

We also, however, want the wasm32-unknown-wasi target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the wasm32-unknown-wasi target:

By default the C standard library is statically provided inside of
liblibc.rlib distributed as part of the sysroot. This means that
you can rustc foo.wasm --target wasm32-unknown-unknown and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of rust-lld is used to
link binaries.
For linking with C code, the -C target-feature=-crt-static flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external clang
compiler configured with its own sysroot. Therefore you'll typically
use this flag with -C linker=/path/to/clang-script-wrapper. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.

Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.

rust-highfive · 2019-03-27T16:23:45Z

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2019-03-27T16:25:30Z

This is coupled with rust-lang/libc#1307 for the libc crate changes, and we'll need to publish that before merging this.

r? @fitzgen

fitzgen

🎉

src/bootstrap/compile.rs

src/librustc_target/spec/wasm32_unknown_wasi.rs

fitzgen · 2019-03-27T17:07:14Z

src/librustc_target/spec/wasm32_unknown_wasi.rs

+//! The wasi target is **very** new in its specification. It's likely going to
+//! be a long effort to get it standardized and stable. We'll be following it as
+//! best we can with this target. Don't start relying on too much here unless
+//! you know what you're getting in to!


Thanks for this very nice doc comment 👍

fitzgen · 2019-03-27T17:30:20Z

src/libstd/sys/wasi/os.rs

+}
+
+pub fn temp_dir() -> PathBuf {
+    panic!("no filesystem on wasm")


Might make sense to have an inline(never) function that all the unsupported panics defer to. I think this should make code sizes smaller.

Perhaps yeah! I figure we can fix that up as it goes along because unconditionally panicking binaries aren't too useful anyway :)

src/libstd/sys/wasi/os.rs

gnzlbg · 2019-03-27T17:49:03Z

For example should std::fs::File
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.

A WasiFd sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like std::fs::File if we bind wasi file
descriptors exactly.

I'm not sure I understand. Is there something that prevents std::fs::File from being implemented on top of the libc wasi file descriptor? Are you arguing that maybe we should expose a WasiFd instead of std::fs::File for this target ?

rust-highfive · 2019-03-27T17:52:22Z

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

alexcrichton · 2019-03-27T20:47:34Z

Is there something that prevents std::fs::File from being implemented on top of the libc wasi file descriptor? Are you arguing that maybe we should expose a WasiFd instead of std::fs::File for this target ?

This sort of depends on how the file descriptor situation is settled in wasi's sysroot. It seems like there's the concept of a "wasi file descriptor" as well as a "libc file descriptor", indexing different spaces. For those purposes we'd need to convert between them.

This is sort of similar as well to "what if we used FILE as the implementation of std::fs::File on Unix?". I think the answer for wasi is "all primitives should internally contain WasiFd", but we just need to figure out a way how to do that which still interoperates with C code well.

rust-highfive · 2019-03-27T23:30:59Z

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Add intial support for wasm32-unknown-wasi This target is [being proposed][LINK] int he rust-lang/rust repository and this is intended to get coupled with that proposal. The definitions here all match the upstream reference-sysroot definitions and the functions all match the reference sysroot as well. The linkage here is described more in detail on the Rust PR itself, but in general it's similar to musl. Automatic verification has been implemented in the same manner as other targets, and it's been used locally to develop this PR and catch errors in the bindings already written (also to help match the evolving sysroot of wasi). The verification isn't hooked up to CI yet though because there is no wasi target distributed via rustup just yet, but once that's done I'll file a follow-up PR to execute verification on CI. [LINK]: rust-lang/rust#59464

chicoxyzzy · 2019-03-28T03:13:50Z

src/ci/docker/dist-various-2/build-wasi-toolchain.sh

+
+set -ex
+
+curl http://releases.llvm.org/8.0.0/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz | \


Might make sense to use latest LTS (18.04) instead

We will eventually! For now though the rest of the image here is 17.10, but when that upgrades we can upgrade this

Add intial support for wasm32-unknown-wasi This target is [being proposed][LINK] int he rust-lang/rust repository and this is intended to get coupled with that proposal. The definitions here all match the upstream reference-sysroot definitions and the functions all match the reference sysroot as well. The linkage here is described more in detail on the Rust PR itself, but in general it's similar to musl. Automatic verification has been implemented in the same manner as other targets, and it's been used locally to develop this PR and catch errors in the bindings already written (also to help match the evolving sysroot of wasi). The verification isn't hooked up to CI yet though because there is no wasi target distributed via rustup just yet, but once that's done I'll file a follow-up PR to execute verification on CI. [LINK]: rust-lang/rust#59464

sunfishcode · 2019-03-28T14:27:43Z

This sort of depends on how the file descriptor situation is settled in wasi's sysroot. It seems like there's the concept of a "wasi file descriptor" as well as a "libc file descriptor", indexing different spaces. For those purposes we'd need to convert between them.

WASI uses __wasi_fd_t which is unsigned, while libc/POSIX use int which is signed so that it can use negative numbers to indicate errors, but it's the same index space.

alexcrichton · 2019-03-28T14:32:20Z

@sunfishcode oh ok thanks! So the idea is that a libc file descriptor is interchangeable with a wasi file descriptor? If that's the case sounds like we'll be using a design similar to unix for libstd where every type just internally contains a 32-bit file descriptor (probably the WasiFd type in this PR)

sunfishcode · 2019-03-28T23:38:48Z

Yes, they're interchangeable. (If WASI ever produces an fd >= 2³¹, libc might get confused, but realistically you'll hit other limits well before that happens.)

bors · 2019-03-29T18:08:27Z

📌 Commit e59ddbf2e8f43385ede4833abc2d2edf3c5e9881 has been approved by fitzgen

bors · 2019-03-29T18:09:33Z

⌛ Testing commit e59ddbf2e8f43385ede4833abc2d2edf3c5e9881 with merge a31f4e2bc6c22c03455e0a36ceb9ce3a1049fce8...

Centril · 2019-03-29T18:09:48Z

@bors retry

bors · 2019-03-29T21:45:36Z

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout wasi-pr (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self wasi-pr --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/bootstrap/compile.rs
Auto-merging src/bootstrap/bin/rustc.rs
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

This commit adds a new wasm32-based target distributed through rustup, supported in the standard library, and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem, networking, threads, etc. Instead it only provides the most basic of integration with the wasi syscalls, enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit, abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target, but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime], but more will surely emerge! In terms of future development of libstd, I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls, but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear, therefore, how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit, but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust, and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library, there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot, for example, provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management, process exit, and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way, if Rust and C are linked into the same WebAssembly binary they should work together, but that requires that the same C standard library is used. We also, however, want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind, there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go, a fully workable wasi binary pops out. This is incompatible with linking in C code, however, which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code, the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag, but the idea is that you're no longer using the provided static C runtime, but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols, but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:

alexcrichton · 2019-03-29T22:58:49Z

@bors: r=fitzgen

bors · 2019-03-29T22:58:50Z

📌 Commit ace7124 has been approved by fitzgen

bors · 2019-03-30T02:34:21Z

⌛ Testing commit ace7124 with merge 709b72e...

Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup, supported in the standard library, and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem, networking, threads, etc. Instead it only provides the most basic of integration with the wasi syscalls, enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit, abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target, but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime], but more will surely emerge! In terms of future development of libstd, I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls, but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear, therefore, how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit, but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust, and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library, there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot, for example, provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management, process exit, and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way, if Rust and C are linked into the same WebAssembly binary they should work together, but that requires that the same C standard library is used. We also, however, want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind, there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go, a fully workable wasi binary pops out. This is incompatible with linking in C code, however, which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code, the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag, but the idea is that you're no longer using the provided static C runtime, but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols, but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ [wasmtime]: https://github.com/cranestation/wasmtime-wasi

bors · 2019-03-30T06:05:49Z

☀️ Test successful - checks-travis, status-appveyor
Approved by: fitzgen
Pushing 709b72e to master...

Version 1.35.0 (2019-05-23) ========================== Language -------- - [`FnOnce`, `FnMut`, and the `Fn` traits are now implemented for `Box<FnOnce>`, `Box<FnMut>`, and `Box<Fn>` respectively.][59500] - [You can now coerce closures into unsafe function pointers.][59580] e.g. ```rust unsafe fn call_unsafe(func: unsafe fn()) { func() } pub fn main() { unsafe { call_unsafe(|| {}); } } ``` Compiler -------- - [Added the `armv6-unknown-freebsd-gnueabihf` and `armv7-unknown-freebsd-gnueabihf` targets.][58080] - [Added the `wasm32-unknown-wasi` target.][59464] Libraries --------- - [`Thread` will now show its ID in `Debug` output.][59460] - [`StdinLock`, `StdoutLock`, and `StderrLock` now implement `AsRawFd`.][59512] - [`alloc::System` now implements `Default`.][59451] - [Expanded `Debug` output (`{:#?}`) for structs now has a trailing comma on the last field.][59076] - [`char::{ToLowercase, ToUppercase}` now implement `ExactSizeIterator`.][58778] - [All `NonZero` numeric types now implement `FromStr`.][58717] - [Removed the `Read` trait bounds on the `BufReader::{get_ref, get_mut, into_inner}` methods.][58423] - [You can now call the `dbg!` macro without any parameters to print the file and line where it is called.][57847] - [In place ASCII case conversions are now up to 4× faster.][59283] e.g. `str::make_ascii_lowercase` - [`hash_map::{OccupiedEntry, VacantEntry}` now implement `Sync` and `Send`.][58369] Stabilized APIs --------------- - [`f32::copysign`] - [`f64::copysign`] - [`RefCell::replace_with`] - [`RefCell::map_split`] - [`ptr::hash`] - [`Range::contains`] - [`RangeFrom::contains`] - [`RangeTo::contains`] - [`RangeInclusive::contains`] - [`RangeToInclusive::contains`] - [`Option::copied`] Cargo ----- - [You can now set `cargo:rustc-cdylib-link-arg` at build time to pass custom linker arguments when building a `cdylib`.][cargo/6298] Its usage is highly platform specific. Misc ---- - [The Rust toolchain is now available natively for musl based distros.][58575] [59460]: rust-lang/rust#59460 [59464]: rust-lang/rust#59464 [59500]: rust-lang/rust#59500 [59512]: rust-lang/rust#59512 [59580]: rust-lang/rust#59580 [59283]: rust-lang/rust#59283 [59451]: rust-lang/rust#59451 [59076]: rust-lang/rust#59076 [58778]: rust-lang/rust#58778 [58717]: rust-lang/rust#58717 [58369]: rust-lang/rust#58369 [58423]: rust-lang/rust#58423 [58080]: rust-lang/rust#58080 [57847]: rust-lang/rust#57847 [58575]: rust-lang/rust#58575 [cargo/6298]: rust-lang/cargo#6298 [`f32::copysign`]: https://doc.rust-lang.org/stable/std/primitive.f32.html#method.copysign [`f64::copysign`]: https://doc.rust-lang.org/stable/std/primitive.f64.html#method.copysign [`RefCell::replace_with`]: https://doc.rust-lang.org/stable/std/cell/struct.RefCell.html#method.replace_with [`RefCell::map_split`]: https://doc.rust-lang.org/stable/std/cell/struct.RefCell.html#method.map_split [`ptr::hash`]: https://doc.rust-lang.org/stable/std/ptr/fn.hash.html [`Range::contains`]: https://doc.rust-lang.org/std/ops/struct.Range.html#method.contains [`RangeFrom::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeFrom.html#method.contains [`RangeTo::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeTo.html#method.contains [`RangeInclusive::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeInclusive.html#method.contains [`RangeToInclusive::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeToInclusive.html#method.contains [`Option::copied`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.copied

rust-highfive assigned Mark-Simulacrum Mar 27, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 27, 2019

alexcrichton mentioned this pull request Mar 27, 2019

Add intial support for wasm32-unknown-wasi rust-lang/libc#1307

Merged

alexcrichton force-pushed the wasi-pr branch from 1f92bf8 to 8fbc5b8 Compare March 27, 2019 16:26

syrusakbary mentioned this pull request Mar 27, 2019

Add WASI Interface to Wasmer wasmerio/wasmer#297

Closed

fitzgen approved these changes Mar 27, 2019

View reviewed changes

gnzlbg reviewed Mar 27, 2019

View reviewed changes

src/libstd/sys/wasi/os.rs Outdated Show resolved Hide resolved

alexcrichton force-pushed the wasi-pr branch from 8fbc5b8 to 0f0dd71 Compare March 27, 2019 20:45

chicoxyzzy reviewed Mar 28, 2019

View reviewed changes

alexcrichton force-pushed the wasi-pr branch from 0f0dd71 to f21d15b Compare March 29, 2019 02:30

This comment has been minimized.

Sign in to view

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 29, 2019

alexcrichton force-pushed the wasi-pr branch from f21d15b to d73d497 Compare March 29, 2019 02:32

This comment has been minimized.

Sign in to view

ghost mentioned this pull request Mar 29, 2019

How to change memory limits for lucet-wasi bytecodealliance/lucet#74

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 29, 2019

alexcrichton force-pushed the wasi-pr branch from e59ddbf to ace7124 Compare March 29, 2019 22:58

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 29, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 30, 2019

bors merged commit ace7124 into rust-lang:master Mar 30, 2019

chpio mentioned this pull request Apr 2, 2019

Compile to WASM kaj/rsass#33

Open

alexcrichton deleted the wasi-pr branch May 1, 2019 17:49

tpmccallum mentioned this pull request Nov 7, 2019

Accessing console/terminal output and file system WAVM/WAVM#219

Closed

jyn514 mentioned this pull request Feb 28, 2021

Check stability and feature attributes in rustdoc #82598

Merged

davidtwco mentioned this pull request Sep 20, 2023

target tier policy compliance #116004

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a new wasm32-unknown-wasi target #59464

Add a new wasm32-unknown-wasi target #59464

alexcrichton commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

alexcrichton commented Mar 27, 2019

fitzgen left a comment

fitzgen Mar 27, 2019

fitzgen Mar 27, 2019

alexcrichton Mar 27, 2019

gnzlbg commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

alexcrichton commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

chicoxyzzy Mar 28, 2019

alexcrichton Mar 28, 2019

sunfishcode commented Mar 28, 2019

alexcrichton commented Mar 28, 2019

sunfishcode commented Mar 28, 2019 •

edited

Loading

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

bors commented Mar 29, 2019

bors commented Mar 29, 2019

Centril commented Mar 29, 2019

bors commented Mar 29, 2019

alexcrichton commented Mar 29, 2019

bors commented Mar 29, 2019

bors commented Mar 30, 2019

bors commented Mar 30, 2019


		set -ex

		curl http://releases.llvm.org/8.0.0/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz \| \

Add a new wasm32-unknown-wasi target #59464

Add a new wasm32-unknown-wasi target #59464

Conversation

alexcrichton commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

alexcrichton commented Mar 27, 2019

fitzgen left a comment

Choose a reason for hiding this comment

fitzgen Mar 27, 2019

Choose a reason for hiding this comment

fitzgen Mar 27, 2019

Choose a reason for hiding this comment

alexcrichton Mar 27, 2019

Choose a reason for hiding this comment

gnzlbg commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

alexcrichton commented Mar 27, 2019

rust-highfive commented Mar 27, 2019

chicoxyzzy Mar 28, 2019

Choose a reason for hiding this comment

alexcrichton Mar 28, 2019

Choose a reason for hiding this comment

sunfishcode commented Mar 28, 2019

alexcrichton commented Mar 28, 2019

sunfishcode commented Mar 28, 2019 • edited Loading

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

bors commented Mar 29, 2019

bors commented Mar 29, 2019

Centril commented Mar 29, 2019

bors commented Mar 29, 2019

alexcrichton commented Mar 29, 2019

bors commented Mar 29, 2019

bors commented Mar 30, 2019

bors commented Mar 30, 2019

sunfishcode commented Mar 28, 2019 •

edited

Loading