Omit the vendor component in the WASI triple

This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
This commit is contained in:
Dan Gohman 2019-04-30 19:37:25 -07:00
parent ef01f29964
commit 1fe3ce1c42
6 changed files with 23 additions and 23 deletions

View file

@ -480,7 +480,7 @@
# linked binaries
#musl-root = "..."
# The root location of the `wasm32-unknown-wasi` sysroot.
# The root location of the `wasm32-wasi` sysroot.
#wasi-root = "..."
# Used in testing for configuring where the QEMU images are located, you

View file

@ -69,7 +69,7 @@ ENV TARGETS=x86_64-fuchsia
ENV TARGETS=$TARGETS,aarch64-fuchsia
ENV TARGETS=$TARGETS,sparcv9-sun-solaris
ENV TARGETS=$TARGETS,wasm32-unknown-unknown
ENV TARGETS=$TARGETS,wasm32-unknown-wasi
ENV TARGETS=$TARGETS,wasm32-wasi
ENV TARGETS=$TARGETS,x86_64-sun-solaris
ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32
ENV TARGETS=$TARGETS,x86_64-unknown-cloudabi
@ -79,5 +79,5 @@ ENV TARGETS=$TARGETS,nvptx64-nvidia-cuda
ENV X86_FORTANIX_SGX_LIBS="/x86_64-fortanix-unknown-sgx/lib/"
ENV RUST_CONFIGURE_ARGS --enable-extended --enable-lld --disable-docs \
--set target.wasm32-unknown-wasi.wasi-root=/wasm32-unknown-wasi
--set target.wasm32-wasi.wasi-root=/wasm32-wasi
ENV SCRIPT python2.7 ../x.py dist --target $TARGETS

View file

@ -13,7 +13,7 @@ git clone https://github.com/CraneStation/wasi-sysroot
cd wasi-sysroot
git reset --hard e5f14be38362f1ab83302895a6e74b2ffd0e2302
make -j$(nproc) INSTALL_DIR=/wasm32-unknown-wasi install
make -j$(nproc) INSTALL_DIR=/wasm32-wasi install
cd ..
rm -rf reference-sysroot-wasi

View file

@ -444,7 +444,7 @@ fn $module() {
("asmjs-unknown-emscripten", asmjs_unknown_emscripten),
("wasm32-unknown-emscripten", wasm32_unknown_emscripten),
("wasm32-unknown-unknown", wasm32_unknown_unknown),
("wasm32-unknown-wasi", wasm32_unknown_wasi),
("wasm32-wasi", wasm32_wasi),
("wasm32-experimental-emscripten", wasm32_experimental_emscripten),
("thumbv6m-none-eabi", thumbv6m_none_eabi),

View file

@ -1,4 +1,4 @@
//! The `wasm32-unknown-wasi` target is a new and still (as of March 2019)
//! The `wasm32-wasi` target is a new and still (as of April 2019) an
//! experimental target. The definition in this file is likely to be tweaked
//! over time and shouldn't be relied on too much.
//!
@ -13,14 +13,14 @@
//! serve two use cases here with this target:
//!
//! * First, we want Rust usage of the target to be as hassle-free as possible,
//! ideally avoiding the need to configure and install a local
//! wasm32-unknown-wasi toolchain.
//! ideally avoiding the need to configure and install a local wasm32-wasi
//! toolchain.
//!
//! * Second, one of the primary use cases of LLVM's new wasm backend and the
//! wasm support in LLD is that any compiled language can interoperate with
//! any other. To that the `wasm32-unknown-wasi` target is the first with a
//! viable C standard library and sysroot common definition, so we want Rust
//! and C/C++ code to interoperate when compiled to `wasm32-unknown-unknown`.
//! any other. To that the `wasm32-wasi` target is the first with a viable C
//! standard library and sysroot common definition, so we want Rust and C/C++
//! code to interoperate when compiled to `wasm32-unknown-unknown`.
//!
//! You'll note, however, that the two goals above are somewhat at odds with one
//! another. To attempt to solve both use cases in one go we define a target
@ -39,8 +39,8 @@
//! necessary.
//!
//! All in all, by default, no external dependencies are required. You can
//! compile `wasm32-unknown-wasi` binaries straight out of the box. You can't,
//! however, reliably interoperate with C code in this mode (yet).
//! compile `wasm32-wasi` binaries straight out of the box. You can't, however,
//! reliably interoperate with C code in this mode (yet).
//!
//! ## Interop with C required
//!
@ -53,17 +53,17 @@
//!
//! 2. If you're using rustc to build a linked artifact then you'll need to
//! specify `-C linker` to a `clang` binary that supports
//! `wasm32-unknown-wasi` and is configured with the `wasm32-unknown-wasi`
//! sysroot. This will cause Rust code to be linked against the libc.a that
//! the specified `clang` provides.
//! `wasm32-wasi` and is configured with the `wasm32-wasi` sysroot. This
//! will cause Rust code to be linked against the libc.a that the specified
//! `clang` provides.
//!
//! 3. If you're building a staticlib and integrating Rust code elsewhere, then
//! compiling with `-C target-feature=-crt-static` is all you need to do.
//!
//! You can configure the linker via Cargo using the
//! `CARGO_TARGET_WASM32_UNKNOWN_WASI_LINKER` env var. Be sure to also set
//! `CC_wasm32-unknown-wasi` if any crates in the dependency graph are using
//! the `cc` crate.
//! `CARGO_TARGET_WASM32_WASI_LINKER` env var. Be sure to also set
//! `CC_wasm32-wasi` if any crates in the dependency graph are using the `cc`
//! crate.
//!
//! ## Remember, this is all in flux
//!
@ -82,7 +82,7 @@ pub fn target() -> Result<Target, String> {
.pre_link_args
.entry(LinkerFlavor::Gcc)
.or_insert(Vec::new())
.push("--target=wasm32-unknown-wasi".to_string());
.push("--target=wasm32-wasi".to_string());
// When generating an executable be sure to put the startup object at the
// front so the main function is correctly hooked up.
@ -98,13 +98,13 @@ pub fn target() -> Result<Target, String> {
options.crt_static_respected = true;
Ok(Target {
llvm_target: "wasm32-unknown-wasi".to_string(),
llvm_target: "wasm32-wasi".to_string(),
target_endian: "little".to_string(),
target_pointer_width: "32".to_string(),
target_c_int_width: "32".to_string(),
target_os: "wasi".to_string(),
target_env: String::new(),
target_vendor: "unknown".to_string(),
target_vendor: String::new(),
data_layout: "e-m:e-p:32:32-i64:64-n32:64-S128".to_string(),
arch: "wasm32".to_string(),
linker_flavor: LinkerFlavor::Lld(LldFlavor::Wasm),

View file

@ -108,7 +108,7 @@
"thumbv8m.main-none-eabihf",
"wasm32-unknown-emscripten",
"wasm32-unknown-unknown",
"wasm32-unknown-wasi",
"wasm32-wasi",
"x86_64-apple-darwin",
"x86_64-apple-ios",
"x86_64-fortanix-unknown-sgx",