Add a new `wasm32-wasip1` target to rustc #120468

alexcrichton · 2024-01-29T17:12:04Z

This commit adds a new target called wasm32-wasip1 to rustc. This new target is explained in these two MCPs:

In short, the previous wasm32-wasi target is going to be renamed to wasm32-wasip1 to better live alongside the new wasm32-wasip2 target. 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.

rustbot · 2024-01-29T17:12:12Z

r? @compiler-errors

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

rustbot · 2024-01-29T17:12:15Z

This PR modifies config.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

These commits modify compiler targets.
(See the Target Tier Policy.)

alexcrichton · 2024-01-29T17:22:01Z

compiler/rustc_target/src/spec/targets/wasm32_wasi_preview1.rs

+//!
+//! Note that this target was historically called `wasm32-wasi` originally and
+//! was since renamed to `wasm32-wasi-preview1` after the preview2 target was
+//! introduced.


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.

src/doc/rustc/src/platform-support/wasm32-wasi-preview1.md

compiler-errors · 2024-01-29T18:37:57Z

r? @wesleywiser

src/doc/rustc/src/platform-support.md

bors · 2024-01-30T20:16:28Z

☔ The latest upstream changes (presumably #120496) made this pull request unmergeable. Please resolve the merge conflicts.

wesleywiser · 2024-01-30T23:18:46Z

@bors r+

bors · 2024-01-30T23:18:48Z

📌 Commit e7c1b37 has been approved by wesleywiser

It is now in the queue for this repository.

syrusakbary · 2024-01-31T10:38:26Z

I'm extremely concerned about renaming wasm32-wasi to wasm32-wasi-preview1, if then we do use the this target in the future for something else.
Why? this will break compatibility and many workloads that assume that the wasm32-wasi target is indeed the Preview 1 implementation.

I would recommend keep using wasm32-wasi for Preview 1 and create a new target for Preview 2 (wasm32-wasi-preview2) without actually having to break compatibility, specially given that preview 2 is a preview and not final version of WASI. / cc @alexcrichton

Note

I would have commented on the original MCP issue, but I'm actually blocked to perform that action

wesleywiser · 2024-01-31T15:30:40Z

@syrusakbary a new target for wasm32-wasi-preview2 is being created, wasm32-wasi is not being repurposed to target WASI preview 2. My understanding is that the eventual plan is for wasm32-wasi to target WASI (preview nothing) when that is stabilized but there is currently no timeline for that to happen.

alexcrichton · 2024-01-31T21:19:44Z

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!

wesleywiser · 2024-03-04T18:46:56Z

@bors r+

bors · 2024-03-04T18:46:58Z

📌 Commit cb39d6c has been approved by wesleywiser

It is now in the queue for this repository.

bors · 2024-03-04T18:46:59Z

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

bors · 2024-03-04T18:55:17Z

⌛ Testing commit cb39d6c with merge d18480b...

bors · 2024-03-04T21:29:47Z

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing d18480b to master...

rust-timer · 2024-03-04T22:52:50Z

Finished benchmarking commit (d18480b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.5%	[-5.5%, -2.1%]	13
Improvements ✅ (secondary)	-2.9%	[-4.8%, -0.5%]	59
All ❌✅ (primary)	-3.5%	[-5.5%, -2.1%]	13

Cycles

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.1%, 2.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 645.218s -> 643.087s (-0.33%)
Artifact size: 175.01 MiB -> 174.99 MiB (-0.01%)

alexcrichton · 2024-03-05T03:06:45Z

Filling in the schedule from the MCP gives:

date	Rust Stable	Rust Beta	Rust Nightly	Notes
2024-02-08	1.76	1.77	1.78	add support for `wasm32-wasi-preview1` (1, 2)
2024-03-21	1.77	1.78	1.79
2024-05-02	1.78	1.79	1.80
2024-06-13	1.79	1.80	1.81	warn on `wasm32-wasi` (4)
2024-07-25	1.80	1.81	1.82
2024-09-05	1.81	1.82	1.83
2024-10-17	1.82	1.83	1.84	remove `wasm32-wasi` (5)
2024-11-28	1.83	1.84	1.85
2025-01-09	1.84	1.85	1.86	`wasm32-wasi` is now gone on all release channels

I'll schedule a notification for myself in mid-Junue to land the change to warn on usage of wasm32-wasi.

eminence · 2024-03-05T03:48:09Z

2024-01-09 wasm32-wasi is now gone on all release channels

This should read 2025, right?

alexcrichton · 2024-03-05T15:28:44Z

Oops, yes

alexcrichton · 2024-03-05T15:46:22Z

@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:

This release introduces a new compiler target: wasm32-wasip1. This target is the exact same as the wasm32-wasi target except in name. Originally proposed in rust-lang/compiler-team#607 the rollout plan for this new target was later adapted in rust-lang/compiler-team#695. In short this new target will, in 2025, replace the wasm32-wasi target. The wasm32-wasi target is going to remain until the Rust 1.84 stable release in January 2025, giving users a chance to transition from the wasm32-wasi name to wasm32-wasip1. Users of wasm32-wasi will start to receive warnings about the rename in Rust 1.81 to be released in September 2024 before the final removal.

The summary of the motivation for this rename is that the WASI subgroup has approved a new 0.2.0 release of the WASI specifications which is a major change from the previous version. Support for "WASIp2" is present on Nightly Rust in the form of wasm32-wasip2 and the wasm32-wasip1 target name more closely aligns with the future development of WASI.

syrusakbary · 2024-03-06T17:24:32Z

Hey @alexcrichton, the comment you did yesterday is the first time I heard that the wasm32-wasi target will be removed (I assume, with the intention, to later point to another version) starting Jan 2025.
This decision will break many CI workloads, as I actively commented many times in this thread.

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.

Actually we've had some further discussion about this target at the BA meetup currently happening today

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.
I'd like to revisit this decision, because, again... I think it will impact negatively many workloads.

eminence · 2024-03-06T18:10:49Z

This decision will break many CI workloads

It seems like 10 months is plenty of time to make the migration from wasm32-wasi to wasm32-wasip1 (which I think is just a simple textural search and replace). Are you saying that is not enough time for you and your projects?

bjorn3 · 2024-03-06T18:26:46Z

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.

alexcrichton · 2024-03-07T15:27:58Z

To add to what others have already mentioned:

Where was this discussed publicly?
[...]
the comment you did yesterday is the first time I heard that the wasm32-wasi target will be removed (I assume, with the intention, to later point to another version) starting Jan 2025.

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.

I also realized that the decision was taken in a private Bytecode Alliance meetup

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'd expect a decision of such caliber to at least be voted publicly in a WASI meeting

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.

being taken behind closed doors

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.

syrusakbary · 2024-03-08T14:25:18Z

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 wasm32-wasi target in less than a year is not wise and will break many workloads. This also implies that the wasm32-wasi in Rust will be actually different than the same target in Clang when using libc (Preview 1). This is not my opinion, is just the reality.

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 wasm32-wasi target in Rust is not the right path to take, how do you think would be best to proceed? @alexcrichton @bjorn3

alexcrichton · 2024-03-08T18:40:22Z

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 wasm32-wasi is not an option, which is why there's a transition plan in place.

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 wasm32-wasi would be about something different from WASI's design as worked on by the subgroup. If, however, you're instead disagreeing mainly with the recommendation itself, then I would suggest that this isn't the right forum to express that disagreement, and that you should see if you can make compelling arguments to the WASI subgroup to revisit this decision.

syrusakbary · 2024-03-08T23:44:05Z

I think you're right that consistent naming of these targets is desirable

I'm happy that we can agree on this.

You could also have replied when Wesley to you in January

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 wasm32-wasi target was not actually going to break, which is my main reason for concern.

is the transition period here not long enough?

This question is fully missing the point.
Let me explain why: the issue is not the transition period length, the issue is about having a breaking change in the target name, moving away from what clang also considers as wasm32-wasi (being preview 1) and breaking existing compatibility with already existing Rust workloads that target wasm32-wasi.
This are my main arguments. And unfortunately I don't see those debated or discussed anywhere.

Or are you saying that the Rust project shouldn't ever follow the WASI subgroup's recommendation?

Please let me know where I can find that the WASI subgroup recommended as a whole to remove wasm32-wasi, because maybe I missed it when reading the meeting notes. The whole meeting notes are mainly about Preview 2 plan, and a bit of Preview 3.
Regarding wasm32-wasi I only see a single comment from Pat Hickey referencing it, but one can easily imply that there not a specific date or plan in mind, is not definitive, nor it can be interpreted that the WASI subgroup made that decision as a whole ("one day wasm32-wasi may be removed or changed to mean WASI 1.0").

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 wasm32-wasi target should have been planned so everyone that have an opinion can plan to attend the meeting and reflect their opinion with their vote. I hope we can agree on that.

In any case, I do reiterate, removing the wasm32-wasi target in Rust is a big concern for the reasons described before. So, being where we are today, how do you suggest we can move forward?

jeffparsons · 2024-03-09T01:07:59Z

the issue is not the transition period length, the issue is about having a breaking change in the target name

Even as a relatively casual observer, it has been clear to me for about a year that the general consensus was that wasm32-wasi should eventually be freed up to make way for "WASI 1.0". You might even say that using it to refer to "preview 1" is regarded, in retrospect, as having been a mistake.

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 wasm32-wasi, and the cost will be relatively small. Specifically, it will:

Only require superficial changes to code to adjust for — in most cases, literally just a string search and replace.
Only affect people who are rebuilding code that targets preview1, who are also upgrading to new Rust releases.

I am struggling to imagine who these people are who are actively upgrading their Rust toolchain, but who can not comfortably replace the string "wasm32-wasm" with "wasm32-wasip1" some time in the space of about a year.

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)

rustbot assigned compiler-errors Jan 29, 2024

alexcrichton force-pushed the start-wasm32-wasi-rename branch from 699feab to baa7045 Compare January 29, 2024 17:16

alexcrichton mentioned this pull request Jan 29, 2024

Rename wasm32-wasi to wasm32-wasi-preview1 #110596

Closed

alexcrichton commented Jan 29, 2024

View reviewed changes

This comment has been minimized.

Sign in to view

programmerjake reviewed Jan 29, 2024

View reviewed changes

src/doc/rustc/src/platform-support/wasm32-wasi-preview1.md Outdated Show resolved Hide resolved

programmerjake reviewed Jan 29, 2024

View reviewed changes

src/doc/rustc/src/platform-support/wasm32-wasi-preview1.md Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

rustbot assigned wesleywiser and unassigned compiler-errors Jan 29, 2024

This comment has been minimized.

Sign in to view

wesleywiser approved these changes Jan 30, 2024

View reviewed changes

src/doc/rustc/src/platform-support.md Outdated Show resolved Hide resolved

alexcrichton force-pushed the start-wasm32-wasi-rename branch from e4bb7b0 to e7c1b37 Compare January 30, 2024 21:31

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 Jan 30, 2024

alexcrichton mentioned this pull request Jan 31, 2024

Add a new wasm32-wasi-preview2 target #119616

Merged

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 4, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 4, 2024

bors merged commit d18480b into rust-lang:master Mar 4, 2024
12 checks passed

rustbot added this to the 1.78.0 milestone Mar 4, 2024

This was referenced Mar 4, 2024

[WIP] Linker flavors: next steps #119906

Closed

LLVM Bitcode Linker: A self contained linker for nvptx and other targets #117458

Merged

alexcrichton deleted the start-wasm32-wasi-rename branch March 5, 2024 02:55

This was referenced Mar 5, 2024

Renaming the WASI target in Rust 1.71.0 rust-lang/blog.rust-lang.org#1099

Closed

Tracking Issue for Compiler MCP 607: Rename wasm32-wasi target to wasm32-wasi-preview1 #113364

Open

rustbot added the relnotes Marks issues that should be documented in the release notes of the next release. label Mar 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a new `wasm32-wasip1` target to rustc #120468

Add a new `wasm32-wasip1` target to rustc #120468

alexcrichton commented Jan 29, 2024 •

edited

rustbot commented Jan 29, 2024

rustbot commented Jan 29, 2024

alexcrichton Jan 29, 2024

This comment has been minimized.

This comment has been minimized.

compiler-errors commented Jan 29, 2024

This comment has been minimized.

bors commented Jan 30, 2024

wesleywiser commented Jan 30, 2024

bors commented Jan 30, 2024

syrusakbary commented Jan 31, 2024 •

edited

wesleywiser commented Jan 31, 2024

alexcrichton commented Jan 31, 2024

wesleywiser commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

rust-timer commented Mar 4, 2024

alexcrichton commented Mar 5, 2024 •

edited

eminence commented Mar 5, 2024

alexcrichton commented Mar 5, 2024

alexcrichton commented Mar 5, 2024

syrusakbary commented Mar 6, 2024 •

edited

eminence commented Mar 6, 2024

bjorn3 commented Mar 6, 2024

alexcrichton commented Mar 7, 2024

syrusakbary commented Mar 8, 2024

alexcrichton commented Mar 8, 2024

syrusakbary commented Mar 8, 2024 •

edited

jeffparsons commented Mar 9, 2024

Add a new wasm32-wasip1 target to rustc #120468

Add a new wasm32-wasip1 target to rustc #120468

Conversation

alexcrichton commented Jan 29, 2024 • edited

rustbot commented Jan 29, 2024

rustbot commented Jan 29, 2024

alexcrichton Jan 29, 2024

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

compiler-errors commented Jan 29, 2024

This comment has been minimized.

bors commented Jan 30, 2024

wesleywiser commented Jan 30, 2024

bors commented Jan 30, 2024

syrusakbary commented Jan 31, 2024 • edited

wesleywiser commented Jan 31, 2024

alexcrichton commented Jan 31, 2024

wesleywiser commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

bors commented Mar 4, 2024

rust-timer commented Mar 4, 2024

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

alexcrichton commented Mar 5, 2024 • edited

eminence commented Mar 5, 2024

alexcrichton commented Mar 5, 2024

alexcrichton commented Mar 5, 2024

syrusakbary commented Mar 6, 2024 • edited

eminence commented Mar 6, 2024

bjorn3 commented Mar 6, 2024

alexcrichton commented Mar 7, 2024

syrusakbary commented Mar 8, 2024

alexcrichton commented Mar 8, 2024

syrusakbary commented Mar 8, 2024 • edited

jeffparsons commented Mar 9, 2024

Add a new `wasm32-wasip1` target to rustc #120468

Add a new `wasm32-wasip1` target to rustc #120468

alexcrichton commented Jan 29, 2024 •

edited

syrusakbary commented Jan 31, 2024 •

edited

alexcrichton commented Mar 5, 2024 •

edited

syrusakbary commented Mar 6, 2024 •

edited

syrusakbary commented Mar 8, 2024 •

edited