-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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-wasip1
target to rustc
#120468
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
This PR modifies If appropriate, please update These commits modify compiler targets. |
699feab
to
baa7045
Compare
//! | ||
//! Note that this target was historically called `wasm32-wasi` originally and | ||
//! was since renamed to `wasm32-wasi-preview1` after the preview2 target was | ||
//! introduced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll note that this file started as an exact copy of the one from wasm32_wasi.rs
but I took the liberty of updating this (now very old) comment while I was here.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
r? @wesleywiser |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #120496) made this pull request unmergeable. Please resolve the merge conflicts. |
e4bb7b0
to
e7c1b37
Compare
@bors r+ |
I'm extremely concerned about renaming I would recommend keep using Note I would have commented on the original MCP issue, but I'm actually blocked to perform that action |
@syrusakbary a new target for |
Actually we've had some further discussion about this target at the BA meetup currently happening today. We might want to propose a different name for this target given how the WASI subgroup may decide to drop the "preview" terminology when talking about WASI versions. While that discussion is settling and we figure out how best to react to that could this PR be removed from the queue? I'll be sure to follow-up here afterwards after we settle on the naming for sure. I apologize for this coming up late in the process! |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d18480b): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 645.218s -> 643.087s (-0.33%) |
Filling in the schedule from the MCP gives:
I'll schedule a notification for myself in mid-Junue to land the change to warn on usage of |
This should read 2025, right? |
Oops, yes |
@rustbot label +relnotes I want to additionally write at least a small blurb here for the release notes for the future, and I'll also work with @yoshuawuyts to update rust-lang/blog.rust-lang.org#1099 for a longer-form post as well perhaps:
|
Hey @alexcrichton, the comment you did yesterday is the first time I heard that the Where was this discussed publicly? I'd expect a decision of such caliber to at least be voted publicly in a WASI meeting where there are many participants and users that can chime with their opinion.
Upon further reading the comments on this issue, I also realized that the decision was taken in a private Bytecode Alliance meetup, where people belonging to the WASI group can't publicly vote for things. Please note that I'm part of the WASI and WebAssembly Community Groups, and this was never discussed there. I'm quite concerned that decisions of such magnitude being taken behind closed doors without involving the people actually using the technology. |
It seems like 10 months is plenty of time to make the migration from |
On the Rust side rust-lang/compiler-team#607 was the initial MCP (major change proposal) for renaming the wasm32-wasi target. It was seconded April last year. Later rust-lang/compiler-team#695 was opened to suggest extending the period over which the transition happens and this was also accepted. All MCP's are publicly discussed on the rust-lang zulip, but I realize that not everyone watches this location. When the original MCP was opened, rust-lang/blog.rust-lang.org#1099 was also opened to notify users about the upcoming changes. It hasn't been merged yet, a request has been made to update it for the new schedule a couple of hours ago. On the bytecodealliance side I found a public heads up on zulip right after the second MCP was accepted. I'm not aware of any closed door discussion about this change. (I couldn't find anything about it in the public meeting minutes for wasmtime and I have only actually attended the wasmtime meeting once or twice long before wasip2 existed.) There has been a suggestion to teach rustc about renamed targets to give a more helpful error message that indicates that the target was renamed : #110596 (comment) This hasn't been implemented yet though. |
To add to what others have already mentioned:
As @bjorn3 mentioned, this was discussed in various places before. That includes this very PR, where despite what you're saying now, on January 31 you asked about the same issue, and got a reply to the same effect from Wesley.
This is not correct and is a mischaracterization of what happened. At a meetup we had an idea so I put this PR on hold to align with the naming scheme Go established. Later in an official WASI SG meeting, which the notes say you were not present at, the naming of "WASIpX" was discussed and agreed upon. I've noted on this PR as to the rationale here and I've summarized the subgroup's consensus.
I would like to clarify what's happening here to make sure we're all clear. The WASI subgroup does not make decisions for the Rust project, and can only make recommendations. Rust project decisions are made through MCPs, as @bjorn3 has linked.
I would encourage you to assume good faith here instead of assuming bad faith. As laid out above, no decisions have been made behind any closed doors, especially in the BA. And nor could they have been, because the Rust project wouldn't be beholden to any decisions made in the BA. Your comment above, and historical comments on this PR and a sibling PR, indicate to me at least that you're not reading very deeply into decisions/comments being made. I think I've linked the MCPs in many places now for you personally as you keep asking questions that are answered in them. To put it bluntly it feels like you're pointing at a bunch of open doors and claiming they're all closed. |
I think I mentioned this on other issues, but perhaps it was missed. I was not able to comment on the original MCP issue (and I still am unable): rust-lang/compiler-team#607 (please see screenshot) I don't assume bad faith at all. I just think removing the I'm also aware that I'm not the only one that thinks this decision is unwise. I'm listening you, but I don't think the opinions are being heard, for something that I think is quite important, as I believe affect the whole WASI community. So, if you were in the shoes of the ones that think that removing the |
These changes have been discussed over months here, and are in line with the recommendation the WASI subgroup made. While maybe you weren't able to attend the meeting in which this recommendation was discussed, nobody else raised any concerns. Nor did you raise these concerns to the WASI subgroup after the meeting notes were published. I think you're right that consistent naming of these targets is desirable. My understanding is that that is exactly why the WASI subgroup made this recommendation, choosing Go's target naming as the one to unify on. Based on that, work is also ongoing to change the naming of wasi-sdk's target. And I will reiterate that despite what you're saying, you've clearly been aware of these changes for a while now. I don't know why you're not able to comment on the MCP, but you could have taken lots of other steps: for example you could reach out to the Rust project to find out why you can't comment. You could also have replied when Wesley clarified the plan to you in January. And generally, you could have put more effort into making an argument than simply saying that you're against this change and vaguely alluding to other people who're opposed to it. You have been asked for more details on your argument, but haven't replied, so I'll ask again: is the transition period here not long enough? You have claimed multiple times that this will "break many workloads" but have not attempted to explain why with respect to a long transition period. I think it's safe to say that we're all aware that simply removing Or are you saying that the Rust project shouldn't ever follow the WASI subgroup's recommendation? If so, that would lead to a situation where a Rust target called |
I'm happy that we can agree on this.
Wesley's comment was mainly about wasm32-wasi-preview2, which is why I did not reply before. Since it was mentioned that "there is currently no timeline for that [repurposing wasm32-wasi] to happen", it was easy to assume that the
This question is fully missing the point.
Please let me know where I can find that the WASI subgroup recommended as a whole to remove Of course, I don't know if more things were discussed in that meeting that are not reflected in the meeting notes, but that shall be even a bigger reason for concern. Because a question as important as removing the In any case, I do reiterate, removing the |
Even as a relatively casual observer, it has been clear to me for about a year that the general consensus was that This decision has not been made lightly; nobody wants breaking changes. However, I doubt you will find many people who agree with your strict "no breaking target name change ever" stance. There are benefits of freeing up
I am struggling to imagine who these people are who are actively upgrading their Rust toolchain, but who can not comfortably replace the string Perhaps if you could describe a specific difficult scenario you have in mind, it might shed light on why you consider this to be such a big deal. |
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-%26Stdin) - [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%3CTryReserveError%3E-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#120594) 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)
This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in rust-lang#120468 which landed in Rust 1.78 which became stable on 2024-05-02. This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here]. Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target. [here]: rust-lang#120468 (comment)
…r=michaelwoerister Unconditionally warn on usage of `wasm32-wasi` This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in rust-lang#120468 which landed in Rust 1.78 which became stable on 2024-05-02. This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here]. Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target. [here]: rust-lang#120468 (comment)
Rollup merge of rust-lang#126662 - alexcrichton:warn-on-wasm32-wasi, r=michaelwoerister Unconditionally warn on usage of `wasm32-wasi` This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in rust-lang#120468 which landed in Rust 1.78 which became stable on 2024-05-02. This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here]. Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target. [here]: rust-lang#120468 (comment)
…woerister Unconditionally warn on usage of `wasm32-wasi` This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in #120468 which landed in Rust 1.78 which became stable on 2024-05-02. This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here]. Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target. [here]: rust-lang/rust#120468 (comment)
This commit adds a new target called
wasm32-wasip1
to rustc. This new target is explained in these two MCPs:wasm32-wasi
target towasm32-wasi-preview1
compiler-team#607wasm32-wasi
compiler-team#695In short, the previous
wasm32-wasi
target is going to be renamed towasm32-wasip1
to better live alongside the newwasm32-wasip2
target. This new target is added alongside thewasm32-wasi
target and has the exact same definition as the previous target. This PR is effectively a rename ofwasm32-wasi
towasm32-wasip1
. Note, however, that as explained in rust-lang/compiler-team#695 the previouswasm32-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.