-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a new wasm32-wasip2
target
#119616
Add a new wasm32-wasip2
target
#119616
Conversation
r? @m-ou-se (rustbot has picked a reviewer for you, use r? to override) |
These commits modify compiler targets. These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
0642b4a
to
44696a8
Compare
This comment has been minimized.
This comment has been minimized.
44696a8
to
dcf7c7b
Compare
This comment has been minimized.
This comment has been minimized.
Nothing in that MCP mentions that the |
Leaving target_os as wasi for all wasi related targets is probably an oversight of the MCP. The wasi preview 1 and preview 2 logical OSes have very significant differences that go beyond just the ABI level. I don't believe we would want to rely on Preview 2 and preview 1 differ from each other in the following ways:
Does I tried looking at how Windows versions are handled and surprisingly it seems that cc @alexcrichton. |
Part of the motivation for adding an entirely new target is that existing I bring this up in that this is motivation for not only a new target but additionally a new
This PR is sort of where that TBD is being resolved. Given the motivation for adding a brand new target to rustc this is what additionally motivates the addition of a new I would ideally like to rename the |
I do think that using In the case of |
I think the breakage and what to do can go both ways, so at least in my mind there's not a clear-cut answer of what the best route here is. As you've pointed out a con of changing To me one way to go about solving this is to ignore historical precedent (e.g. the preexisting Given all that I at least personally think it makes sense to have different If you'll continue to walk this hypothetical with me, the next question is that if this state of affairs is desirable does it make sense to retrofit onto the existing ecosystem. Personally I think so. The new component-based target is "new enough" that I'm not sure it's worth it to keep everything working seamlessly as much as possible. This is a good opportunity to rethink what WASI support means and how best to support it. For example That's at least my thinking, although I don't know how best to resolve this still myself. I personally think it's best to go with |
I don't have strong feelings on how to differentiate between preview1 and preview2, but I do have strong opinions that there needs to be some way of doing it. I agree with @alexcrichton that preview2 is different enough from preview1 that it can argued that preview2 is an entirely different OS, but it can also be argued that preview2 is just a newer version of the same logical operating system (albeit with very deep and significant changes!). Looking at how the question of new versions of operating systems are already handled in rustc, there's unfortunately not good, clear precedent for what to do. Windows based targets that want to target older versions that what What all of this seems to indicate is that there is likely no obviously correct answer, and so we should pick something that:
Talking with a few others, it does seem like perhaps |
One more thing worth noting is that Not breaking this use case is very important so target_env is the best way to go |
I was talking with Ryan a bit off-thread as well and I agree now too that |
This comment was marked as resolved.
This comment was marked as resolved.
👍 for r? compiler |
The |
25d3cd2
to
8209450
Compare
5144e61
to
5e9bed7
Compare
For historical reference and if anyone's interested, here's the notes for the last meeting where the naming of "p2" vs "preview2" was discussed. The salient points in the notes, to copy/paste here, are:
This was discussed a bit more in-depth in that meeting that the notes don't capture super well, but the consensus was that the "p2" naming is the best going forward as it means "preview 2" in the standards context, "point two" to folks who just want to know what it is, it aligns with what others are already leaning towards (Go), and it's easier to type. |
Okay, now it looks like it's ready for Bors. 😊 |
@bors r=petrochenkov,m-ou-se |
☀️ Test successful - checks-actions |
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
Finished benchmarking commit (ef32456): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 651.173s -> 651.239s (0.01%) |
…ame, r=wesleywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…ame, r=wesleywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…e, r=wesleywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…e, r=wesleywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…eywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang/rust#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…eywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang/rust#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
…eywiser Add a new `wasm32-wasip1` target to rustc This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs: * rust-lang/compiler-team#607 * rust-lang/compiler-team#695 In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](rust-lang/rust#119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
Pkgsrc changes: * Adapt checksums and patches, some have beene intregrated upstream. Upstream chnages: Version 1.78.0 (2024-05-02) =========================== Language -------- - [Stabilize `#[cfg(target_abi = ...)]`] (rust-lang/rust#119590) - [Stabilize the `#[diagnostic]` namespace and `#[diagnostic::on_unimplemented]` attribute] (rust-lang/rust#119888) - [Make async-fn-in-trait implementable with concrete signatures] (rust-lang/rust#120103) - [Make matching on NaN a hard error, and remove the rest of `illegal_floating_point_literal_pattern`] (rust-lang/rust#116284) - [static mut: allow mutable reference to arbitrary types, not just slices and arrays] (rust-lang/rust#117614) - [Extend `invalid_reference_casting` to include references casting to bigger memory layout] (rust-lang/rust#118983) - [Add `non_contiguous_range_endpoints` lint for singleton gaps after exclusive ranges] (rust-lang/rust#118879) - [Add `wasm_c_abi` lint for use of older wasm-bindgen versions] (rust-lang/rust#117918) This lint currently only works when using Cargo. - [Update `indirect_structural_match` and `pointer_structural_match` lints to match RFC] (rust-lang/rust#120423) - [Make non-`PartialEq`-typed consts as patterns a hard error] (rust-lang/rust#120805) - [Split `refining_impl_trait` lint into `_reachable`, `_internal` variants] (rust-lang/rust#121720) - [Remove unnecessary type inference when using associated types inside of higher ranked `where`-bounds] (rust-lang/rust#119849) - [Weaken eager detection of cyclic types during type inference] (rust-lang/rust#119989) - [`trait Trait: Auto {}`: allow upcasting from `dyn Trait` to `dyn Auto`] (rust-lang/rust#119338) Compiler -------- - [Made `INVALID_DOC_ATTRIBUTES` lint deny by default] (rust-lang/rust#111505) - [Increase accuracy of redundant `use` checking] (rust-lang/rust#117772) - [Suggest moving definition if non-found macro_rules! is defined later] (rust-lang/rust#121130) - [Lower transmutes from int to pointer type as gep on null] (rust-lang/rust#121282) Target changes: - [Windows tier 1 targets now require at least Windows 10] (rust-lang/rust#115141) - [Enable CMPXCHG16B, SSE3, SAHF/LAHF and 128-bit Atomics in tier 1 Windows] (rust-lang/rust#120820) - [Add `wasm32-wasip1` tier 2 (without host tools) target] (rust-lang/rust#120468) - [Add `wasm32-wasip2` tier 3 target] (rust-lang/rust#119616) - [Rename `wasm32-wasi-preview1-threads` to `wasm32-wasip1-threads`] (rust-lang/rust#122170) - [Add `arm64ec-pc-windows-msvc` tier 3 target] (rust-lang/rust#119199) - [Add `armv8r-none-eabihf` tier 3 target for the Cortex-R52] (rust-lang/rust#110482) - [Add `loongarch64-unknown-linux-musl` tier 3 target] (rust-lang/rust#121832) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Bump Unicode to version 15.1.0, regenerate tables] (rust-lang/rust#120777) - [Make align_offset, align_to well-behaved in all cases] (rust-lang/rust#121201) - [PartialEq, PartialOrd: document expectations for transitive chains] (rust-lang/rust#115386) - [Optimize away poison guards when std is built with panic=abort] (rust-lang/rust#100603) - [Replace pthread `RwLock` with custom implementation] (rust-lang/rust#110211) - [Implement unwind safety for Condvar on all platforms] (rust-lang/rust#121768) - [Add ASCII fast-path for `char::is_grapheme_extended`] (rust-lang/rust#121138) Stabilized APIs --------------- - [`impl Read for &Stdin`] (https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#impl-Read-for-&Stdin) - [Accept non `'static` lifetimes for several `std::error::Error` related implementations] (rust-lang/rust#113833) - [Make `impl<Fd: AsFd>` impl take `?Sized`] (rust-lang/rust#114655) - [`impl From<TryReserveError> for io::Error`] (https://doc.rust-lang.org/stable/std/io/struct.Error.html#impl-From-for-Error ) These APIs are now stable in const contexts: - [`Barrier::new()`] (https://doc.rust-lang.org/stable/std/sync/struct.Barrier.html#method.new) Cargo ----- - [Stabilize lockfile v4](rust-lang/cargo#12852) - [Respect `rust-version` when generating lockfile] (rust-lang/cargo#12861) - [Control `--charset` via auto-detecting config value] (rust-lang/cargo#13337) - [Support `target.<triple>.rustdocflags` officially] (rust-lang/cargo#13197) - [Stabilize global cache data tracking] (rust-lang/cargo#13492) Misc ---- - [rustdoc: add `--test-builder-wrapper` arg to support wrappers such as RUSTC_WRAPPER when building doctests] (rust-lang/rust#114651) Compatibility Notes ------------------- - [Many unsafe precondition checks now run for user code with debug assertions enabled] (rust-lang/rust#120863) This change helps users catch undefined behavior in their code, though the details of how much is checked are generally not stable. - [riscv only supports split_debuginfo=off for now] (rust-lang/rust#120518) - [Consistently check bounds on hidden types of `impl Trait`] (rust-lang/rust#121679) - [Change equality of higher ranked types to not rely on subtyping] (rust-lang/rust#118247) - [When called, additionally check bounds on normalized function return type] (rust-lang/rust#118882) - [Expand coverage for `arithmetic_overflow` lint] (rust-lang/rust#119432) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Update to LLVM 18](rust-lang/rust#120055) - [Build `rustc` with 1CGU on `x86_64-pc-windows-msvc`] (rust-lang/rust#112267) - [Build `rustc` with 1CGU on `x86_64-apple-darwin`] (rust-lang/rust#112268) - [Introduce `run-make` V2 infrastructure, a `run_make_support` library and port over 2 tests as example] (rust-lang/rust#113026) - [Windows: Implement condvar, mutex and rwlock using futex] (rust-lang/rust#121956)
Would be nice to see the PR name and description updated to match what actually landed (in particular regarding the target name). This just confused be quite a bit.^^ |
wasm32-wasi-preview2
targetwasm32-wasip2
target
This is the initial implementation of the MCP rust-lang/compiler-team#694 creating a new tier 3 target
wasm32-wasip2
. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the MCP.There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
target_family
namedwasi
is introduced. This target family incorporates all wasi targets includingwasm32-wasi
and its derivativewasm32-wasi-preview1-threads
. The difference betweentarget_family = wasi
andtarget_os = wasi
will become much clearer whenwasm32-wasi
is renamed towasm32-wasi-preview1
and thetarget_os
becomeswasm32-wasi-preview1
. You can read about this target rename in this MCP which has also been seconded and will hopefully be officially approved soon.Additional technical details include:
std::sys::wasi_preview2
andstd::os::wasi_preview2
have been created and mostly use#[path]
annotations on their submodules to reach into the existingwasi
(soon to bewasi_preview1
) modules. Over time the differences betweenwasi_preview1
andwasi_preview2
will grow and most like all#[path]
based module aliases will fall away.wasi-preview2
relies on awasi-sdk
in the same way thatwasi-preview1
does (one must include awasi-root
path in theConfig.toml
pointing to sysroot included in the wasi-sdk). The target should build against wasi-sdk v21 without modifications. However, the wasi-sdk itself is growing preview2 support so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.