Rename wasm32-wasi-preview1-threads to wasm32-wasip1-threads
This commit renames the current `wasm32-wasi-preview1-threads` target to `wasm32-wasip1-threads`. The need for this rename is a bit unfortunate as the previous name was chosen in an attempt to be future-compatible with other WASI targets. Originally this target was proposed to be `wasm32-wasi-threads`, and that's what was originally implemented in wasi-sdk as well. After discussion though and with the plans for the upcoming component-model target (now named `wasm32-wasip2`) the "preview1" naming was chosen for the threads-based target. The WASI subgroup later decided that it was time to drop the "preview" terminology and recommends "pX" instead, hence previous PRs to add `wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`. So, with all that history, the "proper name" for this target is different than its current name, so one way or another a rename is required. This PR proposes renaming this target cold-turkey, unlike `wasm32-wasi` which is having a long transition period to change its name. The threads-based target is predicted to see only a fraction of the traffic of `wasm32-wasi` due to the unstable nature of the WASI threads proposal itself. While I was here I updated the in-tree documentation in the target spec file itself as most of the documentation was copied from the original WASI target and wasn't as applicable to this target. Also, as an aside, I can at least try to apologize for all the naming confusion here, but this is hopefully the last WASI-related rename.
This commit is contained in:
Alex Crichton
parent
d255c6a57c
commit
e1e9d38f58
@ -1581,7 +1581,7 @@ fn $module() {
|
||||
("wasm32-wasi", wasm32_wasi),
|
||||
("wasm32-wasip1", wasm32_wasip1),
|
||||
("wasm32-wasip2", wasm32_wasip2),
|
||||
("wasm32-wasi-preview1-threads", wasm32_wasi_preview1_threads),
|
||||
("wasm32-wasip1-threads", wasm32_wasip1_threads),
|
||||
("wasm64-unknown-unknown", wasm64_unknown_unknown),
|
||||
|
||||
("thumbv6m-none-eabi", thumbv6m_none_eabi),
|
||||
|
||||
@ -1,139 +0,0 @@
|
||||
//! The `wasm32-wasi-preview1-threads` target is a new and still (as of July 2023) an
|
||||
//! experimental target. The definition in this file is likely to be tweaked
|
||||
//! over time and shouldn't be relied on too much.
|
||||
//!
|
||||
//! The `wasi-threads` target is a proposal to define a standardized set of syscalls
|
||||
//! that WebAssembly files can interoperate with. This set of syscalls is
|
||||
//! intended to empower WebAssembly binaries with native capabilities such as
|
||||
//! threads, filesystem access, network access, etc.
|
||||
//!
|
||||
//! You can see more about the proposal at <https://github.com/WebAssembly/wasi-threads>.
|
||||
//!
|
||||
//! The Rust target definition here is interesting in a few ways. We want to
|
||||
//! 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-wasi-preview1-threads
|
||||
//! 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-wasi-preview1-threads` 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
|
||||
//! that (ab)uses the `crt-static` target feature to indicate which one you're
|
||||
//! in.
|
||||
//!
|
||||
//! ## No interop with C required
|
||||
//!
|
||||
//! By default the `crt-static` target feature is enabled, and when enabled
|
||||
//! this means that the bundled version of `libc.a` found in `liblibc.rlib`
|
||||
//! is used. This isn't intended really for interoperation with a C because it
|
||||
//! may be the case that Rust's bundled C library is incompatible with a
|
||||
//! foreign-compiled C library. In this use case, though, we use `rust-lld` and
|
||||
//! some copied crt startup object files to ensure that you can download the
|
||||
//! wasi target for Rust and you're off to the races, no further configuration
|
||||
//! necessary.
|
||||
//!
|
||||
//! All in all, by default, no external dependencies are required. You can
|
||||
//! compile `wasm32-wasi-preview1-threads` binaries straight out of the box. You can't, however,
|
||||
//! reliably interoperate with C code in this mode (yet).
|
||||
//!
|
||||
//! ## Interop with C required
|
||||
//!
|
||||
//! For the second goal we repurpose the `target-feature` flag, meaning that
|
||||
//! you'll need to do a few things to have C/Rust code interoperate.
|
||||
//!
|
||||
//! 1. All Rust code needs to be compiled with `-C target-feature=-crt-static`,
|
||||
//! indicating that the bundled C standard library in the Rust sysroot will
|
||||
//! not be used.
|
||||
//!
|
||||
//! 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-wasi-preview1-threads` and is configured with the `wasm32-wasi-preview1-threads` 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_WASI_LINKER` env var. Be sure to also set
|
||||
//! `CC_wasm32-wasi-preview1-threads` if any crates in the dependency graph are using the `cc`
|
||||
//! crate.
|
||||
//!
|
||||
//! ## Remember, this is all in flux
|
||||
//!
|
||||
//! 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!
|
||||
|
||||
use crate::spec::{base, crt_objects, Cc, LinkSelfContainedDefault, LinkerFlavor, Target};
|
||||
|
||||
pub fn target() -> Target {
|
||||
let mut options = base::wasm::options();
|
||||
|
||||
options.os = "wasi".into();
|
||||
|
||||
options.add_pre_link_args(
|
||||
LinkerFlavor::WasmLld(Cc::No),
|
||||
&["--import-memory", "--export-memory", "--shared-memory"],
|
||||
);
|
||||
options.add_pre_link_args(
|
||||
LinkerFlavor::WasmLld(Cc::Yes),
|
||||
&[
|
||||
"--target=wasm32-wasi-threads",
|
||||
"-Wl,--import-memory",
|
||||
"-Wl,--export-memory,",
|
||||
"-Wl,--shared-memory",
|
||||
],
|
||||
);
|
||||
|
||||
options.pre_link_objects_self_contained = crt_objects::pre_wasi_self_contained();
|
||||
options.post_link_objects_self_contained = crt_objects::post_wasi_self_contained();
|
||||
|
||||
// FIXME: Figure out cases in which WASM needs to link with a native toolchain.
|
||||
options.link_self_contained = LinkSelfContainedDefault::True;
|
||||
|
||||
// Right now this is a bit of a workaround but we're currently saying that
|
||||
// the target by default has a static crt which we're taking as a signal
|
||||
// for "use the bundled crt". If that's turned off then the system's crt
|
||||
// will be used, but this means that default usage of this target doesn't
|
||||
// need an external compiler but it's still interoperable with an external
|
||||
// compiler if configured correctly.
|
||||
options.crt_static_default = true;
|
||||
options.crt_static_respected = true;
|
||||
|
||||
// Allow `+crt-static` to create a "cdylib" output which is just a wasm file
|
||||
// without a main function.
|
||||
options.crt_static_allows_dylibs = true;
|
||||
|
||||
// WASI's `sys::args::init` function ignores its arguments; instead,
|
||||
// `args::args()` makes the WASI API calls itself.
|
||||
options.main_needs_argc_argv = false;
|
||||
|
||||
// And, WASI mangles the name of "main" to distinguish between different
|
||||
// signatures.
|
||||
options.entry_name = "__main_void".into();
|
||||
|
||||
options.singlethread = false;
|
||||
options.features = "+atomics,+bulk-memory,+mutable-globals".into();
|
||||
|
||||
Target {
|
||||
llvm_target: "wasm32-wasi".into(),
|
||||
metadata: crate::spec::TargetMetadata {
|
||||
description: None,
|
||||
tier: None,
|
||||
host_tools: None,
|
||||
std: None,
|
||||
},
|
||||
pointer_width: 32,
|
||||
data_layout: "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20".into(),
|
||||
arch: "wasm32".into(),
|
||||
options,
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,74 @@
|
||||
//! The `wasm32-wasip1-threads` target is an extension of the `wasm32-wasip1`
|
||||
//! target where threads are enabled by default for all crates. This target
|
||||
//! should be considered "in flux" as WASI itself has moved on from "p1" to "p2"
|
||||
//! now and threads in "p2" are still under heavy design.
|
||||
//!
|
||||
//! This target inherits most of the other aspects of `wasm32-wasip1`.
|
||||
//!
|
||||
//! Historically this target was known as `wasm32-wasi-preview1-threads`.
|
||||
|
||||
use crate::spec::{base, crt_objects, Cc, LinkSelfContainedDefault, LinkerFlavor, Target};
|
||||
|
||||
pub fn target() -> Target {
|
||||
let mut options = base::wasm::options();
|
||||
|
||||
options.os = "wasi".into();
|
||||
|
||||
options.add_pre_link_args(
|
||||
LinkerFlavor::WasmLld(Cc::No),
|
||||
&["--import-memory", "--export-memory", "--shared-memory"],
|
||||
);
|
||||
options.add_pre_link_args(
|
||||
LinkerFlavor::WasmLld(Cc::Yes),
|
||||
&[
|
||||
"--target=wasm32-wasip1-threads",
|
||||
"-Wl,--import-memory",
|
||||
"-Wl,--export-memory,",
|
||||
"-Wl,--shared-memory",
|
||||
],
|
||||
);
|
||||
|
||||
options.pre_link_objects_self_contained = crt_objects::pre_wasi_self_contained();
|
||||
options.post_link_objects_self_contained = crt_objects::post_wasi_self_contained();
|
||||
|
||||
// FIXME: Figure out cases in which WASM needs to link with a native toolchain.
|
||||
options.link_self_contained = LinkSelfContainedDefault::True;
|
||||
|
||||
// Right now this is a bit of a workaround but we're currently saying that
|
||||
// the target by default has a static crt which we're taking as a signal
|
||||
// for "use the bundled crt". If that's turned off then the system's crt
|
||||
// will be used, but this means that default usage of this target doesn't
|
||||
// need an external compiler but it's still interoperable with an external
|
||||
// compiler if configured correctly.
|
||||
options.crt_static_default = true;
|
||||
options.crt_static_respected = true;
|
||||
|
||||
// Allow `+crt-static` to create a "cdylib" output which is just a wasm file
|
||||
// without a main function.
|
||||
options.crt_static_allows_dylibs = true;
|
||||
|
||||
// WASI's `sys::args::init` function ignores its arguments; instead,
|
||||
// `args::args()` makes the WASI API calls itself.
|
||||
options.main_needs_argc_argv = false;
|
||||
|
||||
// And, WASI mangles the name of "main" to distinguish between different
|
||||
// signatures.
|
||||
options.entry_name = "__main_void".into();
|
||||
|
||||
options.singlethread = false;
|
||||
options.features = "+atomics,+bulk-memory,+mutable-globals".into();
|
||||
|
||||
Target {
|
||||
llvm_target: "wasm32-wasi".into(),
|
||||
metadata: crate::spec::TargetMetadata {
|
||||
description: None,
|
||||
tier: None,
|
||||
host_tools: None,
|
||||
std: None,
|
||||
},
|
||||
pointer_width: 32,
|
||||
data_layout: "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20".into(),
|
||||
arch: "wasm32".into(),
|
||||
options,
|
||||
}
|
||||
}
|
||||
@ -113,7 +113,7 @@ ENV TARGETS=$TARGETS,aarch64-unknown-fuchsia
|
||||
ENV TARGETS=$TARGETS,wasm32-unknown-unknown
|
||||
ENV TARGETS=$TARGETS,wasm32-wasi
|
||||
ENV TARGETS=$TARGETS,wasm32-wasip1
|
||||
ENV TARGETS=$TARGETS,wasm32-wasi-preview1-threads
|
||||
ENV TARGETS=$TARGETS,wasm32-wasip1-threads
|
||||
ENV TARGETS=$TARGETS,sparcv9-sun-solaris
|
||||
ENV TARGETS=$TARGETS,x86_64-pc-solaris
|
||||
ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32
|
||||
@ -138,7 +138,7 @@ RUN ln -s /usr/include/x86_64-linux-gnu/asm /usr/local/include/asm
|
||||
ENV RUST_CONFIGURE_ARGS --enable-extended --enable-lld --disable-docs \
|
||||
--set target.wasm32-wasi.wasi-root=/wasm32-wasip1 \
|
||||
--set target.wasm32-wasip1.wasi-root=/wasm32-wasip1 \
|
||||
--set target.wasm32-wasi-preview1-threads.wasi-root=/wasm32-wasi-preview1-threads \
|
||||
--set target.wasm32-wasip1-threads.wasi-root=/wasm32-wasip1-threads \
|
||||
--musl-root-armv7=/musl-armv7
|
||||
|
||||
ENV SCRIPT python3 ../x.py dist --host='' --target $TARGETS
|
||||
|
||||
@ -16,7 +16,7 @@ make -j$(nproc) \
|
||||
NM="$bin/llvm-nm" \
|
||||
AR="$bin/llvm-ar" \
|
||||
THREAD_MODEL=posix \
|
||||
INSTALL_DIR=/wasm32-wasi-preview1-threads \
|
||||
INSTALL_DIR=/wasm32-wasip1-threads \
|
||||
install
|
||||
|
||||
cd ..
|
||||
|
||||
@ -62,7 +62,7 @@
|
||||
- [*-unknown-openbsd](platform-support/openbsd.md)
|
||||
- [\*-unknown-uefi](platform-support/unknown-uefi.md)
|
||||
- [wasm32-wasip1](platform-support/wasm32-wasip1.md)
|
||||
- [wasm32-wasi-preview1-threads](platform-support/wasm32-wasi-preview1-threads.md)
|
||||
- [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md)
|
||||
- [wasm32-wasip2](platform-support/wasm32-wasip2.md)
|
||||
- [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md)
|
||||
- [\*-win7-windows-msvc](platform-support/win7-windows-msvc.md)
|
||||
|
||||
@ -190,7 +190,7 @@ target | std | notes
|
||||
`wasm32-unknown-unknown` | ✓ | WebAssembly
|
||||
`wasm32-wasi` | ✓ | WebAssembly with WASI (undergoing a [rename to `wasm32-wasip1`][wasi-rename])
|
||||
[`wasm32-wasip1`](platform-support/wasm32-wasip1.md) | ✓ | WebAssembly with WASI
|
||||
[`wasm32-wasi-preview1-threads`](platform-support/wasm32-wasi-preview1-threads.md) | ✓ | | WebAssembly with WASI Preview 1 and threads
|
||||
[`wasm32-wasip1-threads`](platform-support/wasm32-wasip1-threads.md) | ✓ | | WebAssembly with WASI Preview 1 and threads
|
||||
`x86_64-apple-ios` | ✓ | 64-bit x86 iOS
|
||||
[`x86_64-fortanix-unknown-sgx`](platform-support/x86_64-fortanix-unknown-sgx.md) | ✓ | [Fortanix ABI] for 64-bit Intel SGX
|
||||
`x86_64-fuchsia` | ✓ | Alias for `x86_64-unknown-fuchsia`
|
||||
|
||||
@ -1,12 +1,16 @@
|
||||
# `wasm32-wasi-preview1-threads`
|
||||
# `wasm32-wasip1-threads`
|
||||
|
||||
**Tier: 2**
|
||||
|
||||
The `wasm32-wasi-preview1-threads` target is a new and still (as of July 2023) an
|
||||
experimental target. This target is an extension to `wasm32-wasi-preview1` target,
|
||||
The `wasm32-wasip1-threads` target is a new and still (as of July 2023) an
|
||||
experimental target. This target is an extension to `wasm32-wasip1` target,
|
||||
originally known as `wasm32-wasi`. It extends the original target with a
|
||||
standardized set of syscalls that are intended to empower WebAssembly binaries with
|
||||
native multi threading capabilities.
|
||||
standardized set of syscalls that are intended to empower WebAssembly binaries
|
||||
with native multi threading capabilities.
|
||||
|
||||
> **Note**: Prior to March 2024 this target was known as
|
||||
> `wasm32-wasi-preview1-threads`, and even longer before that it was known as
|
||||
> `wasm32-wasi-threads`.
|
||||
|
||||
[wasi-threads]: https://github.com/WebAssembly/wasi-threads
|
||||
[threads]: https://github.com/WebAssembly/threads
|
||||
@ -26,11 +30,11 @@ This target is cross-compiled. The target supports `std` fully.
|
||||
The Rust target definition here is interesting in a few ways. We want to
|
||||
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-wasi-preview1-threads
|
||||
ideally avoiding the need to configure and install a local wasm32-wasip1-threads
|
||||
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. The `wasm32-wasi-preview1-threads` target is the first with a viable C
|
||||
any other. The `wasm32-wasip1-threads` 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`.
|
||||
|
||||
@ -49,7 +53,7 @@ some copied crt startup object files to ensure that you can download the
|
||||
wasi target for Rust and you're off to the races, no further configuration
|
||||
necessary.
|
||||
All in all, by default, no external dependencies are required. You can
|
||||
compile `wasm32-wasi-preview1-threads` binaries straight out of the box. You can't, however,
|
||||
compile `wasm32-wasip1-threads` binaries straight out of the box. You can't, however,
|
||||
reliably interoperate with C code in this mode (yet).
|
||||
### Interop with C required
|
||||
For the second goal we repurpose the `target-feature` flag, meaning that
|
||||
@ -59,18 +63,18 @@ you'll need to do a few things to have C/Rust code interoperate.
|
||||
not be used.
|
||||
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-wasi-preview1-threads` and is configured with the `wasm32-wasi-preview1-threads` sysroot. This
|
||||
`wasm32-wasip1-threads` and is configured with the `wasm32-wasip1-threads` 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.
|
||||
|
||||
All in all, by default, no external dependencies are required. You can
|
||||
compile `wasm32-wasi-preview1-threads` binaries straight out of the box. You can't, however,
|
||||
compile `wasm32-wasip1-threads` binaries straight out of the box. You can't, however,
|
||||
reliably interoperate with C code in this mode (yet).
|
||||
|
||||
|
||||
Also note that at this time the `wasm32-wasi-preview1-threads` target assumes the
|
||||
Also note that at this time the `wasm32-wasip1-threads` target assumes the
|
||||
presence of other merged wasm proposals such as (with their LLVM feature flags):
|
||||
|
||||
* [Bulk memory] - `+bulk-memory`
|
||||
@ -106,7 +110,7 @@ https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-20
|
||||
and specify path to *wasi-root* `.cargo/config.toml`
|
||||
|
||||
```toml
|
||||
[target.wasm32-wasi-preview1-threads]
|
||||
[target.wasm32-wasip1-threads]
|
||||
wasi-root = ".../wasi-libc/sysroot"
|
||||
```
|
||||
|
||||
@ -118,13 +122,13 @@ After that users can build this by adding it to the `target` list in
|
||||
From Rust Nightly 1.71.1 (2023-08-03) on the artifacts are shipped pre-compiled:
|
||||
|
||||
```text
|
||||
rustup target add wasm32-wasi-preview1-threads --toolchain nightly
|
||||
rustup target add wasm32-wasip1-threads --toolchain nightly
|
||||
```
|
||||
|
||||
Rust programs can be built for that target:
|
||||
|
||||
```text
|
||||
rustc --target wasm32-wasi-preview1-threads your-code.rs
|
||||
rustc --target wasm32-wasip1-threads your-code.rs
|
||||
```
|
||||
|
||||
## Cross-compilation
|
||||
@ -133,7 +137,7 @@ This target can be cross-compiled from any hosts.
|
||||
|
||||
## Testing
|
||||
|
||||
Currently testing is not well supported for `wasm32-wasi-preview1-threads` and the
|
||||
Currently testing is not well supported for `wasm32-wasip1-threads` and the
|
||||
Rust project doesn't run any tests for this target. However the UI testsuite can be run
|
||||
manually following this instructions:
|
||||
|
||||
@ -141,8 +145,8 @@ manually following this instructions:
|
||||
or another engine that supports `wasi-threads` is installed and can be found in the `$PATH` env variable.
|
||||
1. Clone master branch.
|
||||
2. Apply such [a change](https://github.com/g0djan/rust/compare/godjan/wasi-threads...g0djan:rust:godjan/wasi-run-ui-tests?expand=1) with an engine from the step 1.
|
||||
3. Run `./x.py test --target wasm32-wasi-preview1-threads tests/ui` and save the list of failed tests.
|
||||
3. Run `./x.py test --target wasm32-wasip1-threads tests/ui` and save the list of failed tests.
|
||||
4. Checkout branch with your changes.
|
||||
5. Apply such [a change](https://github.com/g0djan/rust/compare/godjan/wasi-threads...g0djan:rust:godjan/wasi-run-ui-tests?expand=1) with an engine from the step 1.
|
||||
6. Run `./x.py test --target wasm32-wasi-preview1-threads tests/ui` and save the list of failed tests.
|
||||
6. Run `./x.py test --target wasm32-wasip1-threads tests/ui` and save the list of failed tests.
|
||||
7. For both lists of failed tests run `cat list | sort > sorted_list` and compare it with `diff sorted_list1 sorted_list2`.
|
||||
@ -49,7 +49,7 @@ this target are:
|
||||
|
||||
This target is cross-compiled. The target includes support for `std` itself,
|
||||
but not all of the standard library works. For example spawning a thread will
|
||||
always return an error (see the `wasm32-wasi-preview1-threads` target for
|
||||
always return an error (see the `wasm32-wasip1-threads` target for
|
||||
example). Another example is that spawning a process will always return an
|
||||
error. Operations such as opening a file, however, will be implemented by
|
||||
calling WASI-defined APIs.
|
||||
|
||||
@ -149,7 +149,7 @@
|
||||
"wasm32-unknown-unknown",
|
||||
"wasm32-wasi",
|
||||
"wasm32-wasip1",
|
||||
"wasm32-wasi-preview1-threads",
|
||||
"wasm32-wasip1-threads",
|
||||
"x86_64-apple-darwin",
|
||||
"x86_64-apple-ios",
|
||||
"x86_64-fortanix-unknown-sgx",
|
||||
|
||||
@ -151,7 +151,7 @@
|
||||
//@ [r72] needs-llvm-components: webassembly
|
||||
//@ [r73] compile-flags:--target wasm32-wasip1
|
||||
//@ [r73] needs-llvm-components: webassembly
|
||||
//@ [r74] compile-flags:--target wasm32-wasi-preview1-threads
|
||||
//@ [r74] compile-flags:--target wasm32-wasip1-threads
|
||||
//@ [r74] needs-llvm-components: webassembly
|
||||
//@ [r75] compile-flags:--target x86_64-apple-ios
|
||||
//@ [r75] needs-llvm-components: x86
|
||||
@ -179,7 +179,6 @@
|
||||
//@ compile-flags: -C opt-level=2
|
||||
|
||||
#![crate_type = "lib"]
|
||||
|
||||
#![feature(no_core, lang_items)]
|
||||
#![crate_type = "lib"]
|
||||
#![no_core]
|
||||
|
||||
@ -492,9 +492,9 @@
|
||||
//@ revisions: wasm32_wasip1
|
||||
//@ [wasm32_wasip1] compile-flags: --target wasm32-wasip1
|
||||
//@ [wasm32_wasip1] needs-llvm-components: webassembly
|
||||
//@ revisions: wasm32_wasi_preview1_threads
|
||||
//@ [wasm32_wasi_preview1_threads] compile-flags: --target wasm32-wasi-preview1-threads
|
||||
//@ [wasm32_wasi_preview1_threads] needs-llvm-components: webassembly
|
||||
//@ revisions: wasm32_wasip1_threads
|
||||
//@ [wasm32_wasip1_threads] compile-flags: --target wasm32-wasip1-threads
|
||||
//@ [wasm32_wasip1_threads] needs-llvm-components: webassembly
|
||||
//@ revisions: wasm32_wasip2
|
||||
//@ [wasm32_wasip2] compile-flags: --target wasm32-wasip2
|
||||
//@ [wasm32_wasip2] needs-llvm-components: webassembly
|
||||
|
||||
Loading…
Reference in New Issue
Block a user